agmsg: cross-vendor messaging for CLI AI agents over a shared SQLite file

The copy-paste courier problem agmsg removes

If you run Claude Code in one terminal and Codex in another, the coordination layer is you. You read what one agent produced, decide what the other needs to know, and paste it. That works for a single exchange and falls apart the moment the two sessions need to react to each other repeatedly, because every round trip costs a human context switch.

agmsg targets exactly that gap. The README frames it as connecting peer sessions across different tools, and it is explicit about what it is not: not MCP, not subagents, not a message queue. The distinction matters. A subagent is a child process the parent manages; an agmsg peer is an independent session in its own terminal that you talk to over the shared store. There is no broker and no server process. The SQLite file is the shared floor, and the agents take turns on it.

The audience is narrow and specific: engineers who already keep several CLI coding agents open at once and want them to exchange messages without a human relaying. If you use one agent, agmsg has nothing to do.

How the SQLite transport actually moves a message

The mechanism is deliberately small. Sending is a call to send.sh that appends a row to the database. Receiving depends on the delivery mode: each agent has a hook, or a Monitor stream, that reads from the shared SQLite file and surfaces incoming messages as text the agent can react to.

The store runs in WAL mode, which the README describes as letting multiple readers and a single writer coexist without conflicts. That is the right choice for this shape of workload, because several agents may be polling while one writes. History is durable: messages stay in the database after a session ends, and history.sh can replay an old room into a fresh agent. That replay path is the part I would lean on most in practice, since it means a restarted session can catch up rather than starting blind.

Two design consequences follow. First, there is no delivery acknowledgement beyond what the database itself records, so a message that is written is written, and nothing retries it. Second, because there is no daemon, nothing is running when no agent is running. Both are consistent with the project's stated position that complexity is the thing being avoided.

Installing agmsg with npx and running your first team

The README lists bash and sqlite3 as the only requirements, noting that macOS ships both and that minimal Linux images may need sqlite3 installed first. The fastest install path needs no clone.

npx agmsg

After that, restart Claude Code, Codex, Gemini CLI, Antigravity or OpenCode so the new skill is picked up. Then invoke the command. The slash form differs by host: Claude Code uses /agmsg, while Codex, Gemini CLI, Antigravity and OpenCode use $agmsg.

On first use the command prompts for a team name and an agent name, then asks you to pick a delivery mode. The README states the default on Claude Code and Codex is monitor, described as real-time push, with Codex delivering through a bridge.

If you would rather inspect the code first or track the latest main, the direct script path is available. The command name you choose determines the skill folder and the invocation prefix.

git clone https://github.com/fujibee/agmsg.git
cd agmsg
./install.sh --cmd m

With --cmd m, the skill lands in ~/.agents/skills/m/ and the invocation becomes /m or $m depending on host. The README notes that --cmd and --agent-type exist only on the direct-script path; npm and the plugin marketplace always install as agmsg. To confirm what you are running, /agmsg version reports a tagged release like v1.0.3, or a checkout ahead of the last release like v1.0.3-6-g1a2b3c4.

Monitor mode, hooks, and the Windows Git Bash constraint

Delivery mode is the setting most likely to surprise you, because it changes how a message reaches the agent rather than what the message contains. Monitor mode pushes in real time; the hook-based path surfaces messages when the host agent checks. The README documents monitor as the default on Claude Code and Codex but does not lay out a full comparison of latency and reliability between the two, so if your workflow depends on tight turn-taking, test both rather than assuming the default is the one you want.

Windows deserves separate attention. The implementation is the Bash script set under scripts/, and the README is blunt that there is no PowerShell reimplementation. On Windows the scripts run through Git Bash, with sqlite3 available on the Git Bash PATH. Native Windows Codex commands and hooks often start from PowerShell, which cannot execute a bare .sh path, so agmsg emits a commandWindows entry that invokes Git Bash. The README's advice is to keep the execution path pinned to Git Bash so all agents share the same $HOME and the same SQLite database. If your agents resolve different home directories, they will not see each other's messages, and nothing in the design will tell you why.

Where a file-backed transport stops being the right tool

The absence of a broker is the feature and the limitation at once. Nothing routes, retries, or guarantees ordering across writers beyond what SQLite provides. If an agent writes a message and the receiving agent is not running, the message sits in the database until something reads it. That is fine for asynchronous collaboration and wrong for anything resembling a request with a deadline.

The stronger constraint is locality. The database is a local file, and the README describes syncing a team between two installs as a separate exercise that goes through the self-hosted reference server documented in docs/remote-setup.md. If your agents run on different machines and you have not set that up, they are not in the same team, regardless of what the team name says.

The project also sits at the boundary of what it can observe. It moves text between sessions; it does not validate that the text is a sensible instruction, and it does not mediate conflicting edits two agents might make to the same file. Two agents in a monitor-mode team can talk to each other indefinitely, which the README demonstrates with tic-tac-toe, and that same property means a loop between two agents is something you manage, not something agmsg prevents.

agmsg against MCP servers and agent frameworks

The obvious alternative is an MCP server that exposes messaging as a tool. The difference is architectural rather than cosmetic. An MCP server is a process the agent connects to, which means a runtime to start, supervise and keep alive. agmsg has no server process at all: the README states plainly that there is no MCP server and no extra runtime, just bash and sqlite3. For a single developer running agents on one laptop, that is the whole argument, because there is nothing to leave running and nothing to restart when it dies.

The trade runs the other way as you scale. A broker-backed or server-backed system can offer delivery guarantees, cross-machine routing and a place to enforce policy. agmsg pushes those concerns onto the filesystem and onto you. It also does not try to be an orchestration framework: the README distinguishes peer sessions from subagents explicitly, so if what you want is a parent agent spawning and supervising children, agmsg is not that, even though spawn can launch a new peer in its own terminal. That peer is an independent session you talk to over agmsg, not a child process this one manages.

Maintenance, licensing and what upgrades cost you

The repository is not archived and the last push was on 2026-08-22, which is recent enough that the project is being worked on. Releases have been frequent: v1.2.1 on 2026-08-18, v1.2.2 on 2026-08-20 and v1.2.3 on 2026-08-22. The CHANGELOG.md and cliff.toml in the repository root indicate changelog generation is part of the release process, and RELEASING.md documents it.

The upgrade cost is mostly a question of which install path you chose. The README is explicit that git clone and the setup.sh curl path install straight from main and are always current, while the npm package and the Claude Code plugin are cut from tagged releases on a cadence and can lag main by a few fixes. If you need a just-merged change, clone. The version string tells you where you stand, since a checkout ahead of the last release reports commits past the tag.

Licensing is MIT, which permits commercial use and modification with the licence and copyright notice preserved. That is a statement about the licence text, not advice about your situation; if you redistribute agmsg inside a product, read LICENSE and PRIVACY.md yourself. PRIVACY.md is worth a look regardless, since the design keeps message history in a local SQLite file that persists after sessions end.

Editorial conclusion

Adopt agmsg if you already run two or more CLI agents in separate terminals and you are tired of pasting one agent's output into another. Do not adopt it if you need a message broker with routing guarantees, or if your agents run on different machines without setting up the self-hosted reference server. Before you commit, install it with npx agmsg, restart your agent, run /agmsg and confirm the team and agent name prompt appears; then check /agmsg version so you know whether you are on a tagged release or a checkout ahead of it.

Frequently asked questions

Official sources

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