agmsg: a SQLite file as the shared floor for Claude Code, Codex, Gemini and Copilot

The copy-paste courier problem

Anyone who has run two or more CLI coding agents in parallel knows the friction. Claude Code finishes a task, you copy its output, paste it into Codex, wait, copy the result back. That loop is slow and error prone. agmsg targets exactly that scenario. It lets Claude Code, Codex, Gemini CLI, GitHub Copilot CLI, Antigravity and OpenCode message each other directly through a shared local SQLite database. The README is explicit about what it is not: not MCP, not subagents, not a message queue. It is a thin transport. The intended user is someone who already runs multiple agents and wants them to cooperate as peers, not someone building a distributed system.

How the SQLite floor works

The core mechanism is simple. Each agent has a hook or a Monitor stream that reads from a shared SQLite file and surfaces incoming messages as text the agent can react to. Sending is a call to send.sh that appends a row. There is no daemon, no socket, no broker. The file is the shared floor and the agents take turns on it. The store runs in WAL mode, which allows multiple readers and a single writer to coexist without conflicts. Messages stay in the database after a session ends, and history.sh can replay an old room into a fresh agent. That design has a clear consequence: if two agents write at the same instant, one write blocks. The README does not describe a retry mechanism, so a failed write likely surfaces as an error the agent must handle. For a tool that claims no complexity, that is an acceptable trade-off, but it means agmsg is not a message queue and should not be used as one.

Delivery modes and the monitor default

On first run, the command prompts for a team name and an agent name, then asks for a delivery mode. The README names two: monitor and bridge. On Claude Code and Codex, the default is monitor, described as real-time push. Codex delivers through a bridge. The distinction matters because each agent handles hooks differently. Monitor mode likely uses a stream that pushes new rows to the agent, while bridge mode probably involves a separate process that relays messages. The README does not detail the bridge implementation, but it does say that Codex delivery hooks are wrapped automatically on Windows because native Codex runs hooks via PowerShell, which cannot execute a bare .sh path. agmsg emits a commandWindows entry that invokes Git Bash. That is a concrete example of how delivery mode is not uniform across agents. You should check the docs for your specific agent before assuming the default works.

Install paths and the version lag trap

There are three install paths. The fastest is npx agmsg, which runs a bootstrapper that downloads and runs setup.sh. There is also a direct script path: git clone the repo, then run ./install.sh. The third path is the Claude Code plugin marketplace: /plugin marketplace add fujibee/agmsg, then /plugin install agmsg@fujibee-agmsg, then /reload-plugins. All paths end up with the skill at ~/.agents/skills/agmsg/. The command name determines the skill folder and the invocation prefix: a slash command for Claude Code and Copilot CLI, a dollar command for Codex, Gemini CLI, Antigravity and OpenCode. The npm package and the Claude Code plugin are cut from tagged releases on a cadence, so they can lag main by a few fixes. The README gives a concrete way to check: /agmsg version prints something like v1.0.3, while a checkout ahead of the last release prints v1.0.3-6-g1a2b3c4. If you need a just-merged change, clone the repo. That is a real maintenance consideration: the easiest install path is not always the newest code.

Windows support is Git Bash or nothing

agmsg is implemented as a set of Bash scripts under scripts/. On Windows, those scripts run through Git Bash, which is the Git for Windows environment with sqlite3 available on its PATH. There is no PowerShell reimplementation. The README warns that native Windows Codex commands and hooks often start from PowerShell, so you must pin the actual agmsg execution path to Git Bash so all agents share the same $HOME and SQLite database. If you do not do that, agents may end up pointing at different databases and the whole point of a shared floor collapses. For Codex specifically, agmsg emits a commandWindows entry that invokes Git Bash, which is a workaround, but it only works if Git Bash is installed and on the expected path. On a minimal Linux container, you may need to install sqlite3 first with sudo apt-get install -y sqlite3. The bootstrap will surface a clear error if sqlite3 is missing, but that is still an extra step.

A real limitation: no broker means no delivery guarantees

Because agmsg is a file, not a queue, there is no acknowledgment mechanism. The README does not mention retries, dead-letter handling, or ordering guarantees beyond what SQLite provides. If an agent is not running, messages accumulate in the database, but nothing pushes them to the agent until it starts and reads. In monitor mode, that may be fine. In a scenario where an agent crashes mid-message, the message is still in the DB, but the agent may not know where it left off. history.sh can replay an old room, but that is a manual step. This makes agmsg the wrong tool for any workflow that requires exactly-once processing or strict ordering across multiple agents. It is also not suitable for multi-machine teams unless you set up the remote setup mentioned in docs/remote-setup.md, which the README only references without explaining. If you need cross-machine messaging, you are on your own to run the reference server.

Alternatives: MCP servers and agent frameworks

The most obvious alternative is MCP, the Model Context Protocol. agmsg explicitly says it is not MCP. An MCP server provides a standardized interface for agents to call tools and access resources, but it requires an extra runtime and a server process. agmsg avoids that by using a file. The trade-off is that MCP gives you a richer protocol with typed tools and structured responses, while agmsg only passes text. If you need agents to invoke functions on each other with arguments and return values, MCP is a better fit. Another alternative is a full agent orchestration framework like LangGraph or CrewAI, which manage subagents and workflows programmatically. Those frameworks treat agents as components you control from code, not as peer sessions that happen to share a terminal. agmsg's approach is the opposite: it connects independent sessions that you already run manually. If you want a human-in-the-loop to stay in control, agmsg fits. If you want automation logic, a framework is more appropriate.

Maintenance and licensing

The project is MIT licensed, which means you can use, modify and redistribute it freely, with attribution. The repository is actively maintained, with releases v1.2.1, v1.2.2 and v1.2.3 pushed within a week in August 2026. The release cadence suggests the project is under active development. The npm package publishes with SLSA provenance and uses npm Trusted Publisher (OIDC), which is a good supply-chain practice. The README does not mention a formal upgrade process beyond reinstalling via the same path. Since the npm package lags main, you should periodically check the version string and reinstall if you need recent fixes. The plugin path also requires a bootstrap on first invocation, which populates the skill directory. That bootstrap is a one-time step, but it means the first run is not instant. Overall, the maintenance cost is low for a single user, but you must be aware of the version lag and the sqlite3 dependency.

Editorial conclusion

Adopt agmsg if you run multiple CLI coding agents on one machine and want them to coordinate without a human copy-pasting between terminals. It is a good fit for small teams, single-user workflows and experiments where a shared SQLite file is acceptable. Do not adopt it if you need guaranteed delivery, message ordering across processes, or a native Windows experience without Git Bash. Before you rely on it, verify that your environment has sqlite3, that all agents point to the same $HOME, and that the delivery mode you choose (monitor, bridge, or poll) matches how each agent handles hooks. The project is MIT licensed, but the npm and plugin packages lag main by design, so check the version string before assuming you have the latest fixes.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes