agmsg is a small thing that lets CLI AI agents message each other. Claude Code, Codex, Gemini CLI and the rest join a team and talk directly over a shared local SQLite file. No daemon, no network, nobody relaying copy-paste in the middle.
More people have been running it lately. It hit #5 Product of the Day on Product Hunt and kept going from there. And the setups people build have gotten ambitious. One pattern I keep seeing: an agent monitors its own progress, and when it gets stuck it consults a second, bigger-picture model to break out of tunnel vision. The whole loop runs with no human decision in the middle. A team of agents, used as a team.
The more of those show up, the more I hear "I want to mix in this agent too" and "I want to run that combination." Good problem to have. But it exposed one that had been quietly growing inside the codebase.
1.1.0 is where I went after that problem and rebuilt how agmsg handles extensibility: how easily, and how safely, you can wire in a new agent.
Why 1.1.0 (not 1.0.7)
Adding a new agent type used to be a chore. The core was littered with branches (if claude-code, do this; if codex, do that), and one new type meant editing those branches in a dozen places. That's a leaky abstraction: the engine knew the name of every type it served.
A single feature would have been a patch release. This rebuilt the foundation, so it got a minor bump instead: 1.1.0. Most of the payoff lands later, in the releases built on top of it.
One type, one directory
The change is small to describe. An agent type is now data plus a behavior plug, each in its own directory. Drop a directory under scripts/drivers/types/, give it a manifest and a few overridable behaviors, and the core picks it up. The core no longer contains a single hardcoded type name. (I called that part engine purification, which is grander than it deserves.)
Think of it as a socket and a plug. The agmsg core is the socket; each agent type is a plug. You add plugs without rewiring the socket. Before, you couldn't add a plug without opening up the socket's internals.
Two things got better in practice.
Adding a type is mostly declarative now. Delivery, for example, became a Template Method: the core owns the flow (apply / on_enable / on_disable / status), and each type overrides only what's specific to it in its own _delivery.sh. Data-driven keys in the manifest (delivery_modes, stop_output, hook_windows_wrap) cover most of the per-type variation without touching shared code. The Codex runtime, which used to be sprinkled around, lives under its own types/codex/ now.
And the core got more maintainable. Pulling hardcoded type names out of shared scripts sounds boring, and it's the part that actually mattered. The engine plays no favorites anymore, so fixing it is easier and adding a type is far less likely to break a neighbor.
Extensible, but on purpose
The plug mechanism has a name in agmsg: a driver. It's the adapter that connects an agent to the core.
Because of drivers, you can add your own agent type. 1.1.0 ships Cursor as the first real showcase of that. The new layout is what makes a newcomer like Cursor a matter of dropping in a manifest and a plug. There's also Hermes, a community-built type, added as beta (based on a contribution from Fewmanism).
This is the part I cared about most. Letting people add a type from outside is one short step from letting unknown code run on your machine. A driver is a shell script. It can do anything. So external drivers are opt-in: nothing loads until you explicitly trust it.
agmsg plugin list # see discovered external drivers (untrusted by default)
agmsg plugin trust # allow a specific, path-pinned driver to load
agmsg plugin untrust # revoke it
A driver someone dropped into the directory does not run on its own. It loads only after a trust you issued, pinned to its path. That closes the obvious hole, an unintended drop-in getting executed, without making extension any harder than dropping in a directory.
Where this is going
What I want from the agmsg ecosystem is plain enough: any agent you use, wired in without much fuss, and safely.
New AI tools ship basically every week. The goal is that "I wish I could connect this one to agmsg" takes a small, safe amount of effort each time. 1.1.0 is undercarriage work toward that. Types are the first thing to become pluggable; storage and delivery come next on the same driver model (ADR 0001/0002 if you want the design notes).
One last thing. Big thanks to the contributors whose PRs this builds on: lucian (@lucianlamp) on the Windows side (1.1.0 also folds in his #186, which drops the PowerShell launcher for a single Git Bash path, plus #187), and Fewmanism on Hermes. agmsg has grown this way the whole time, on the people who use it and the people who put their hands on it.
It's not done. Hermes is beta, a Grok type is something I'd like to build with the community next, and there's hardening left. If you want to wire in your own agent, build a type, or kick the tires on Hermes, all of it is welcome.
One more practical note for anyone already on 1.0.x: install.sh --update now regenerates the Codex monitor wrapper at its new path, so upgrading from 1.0.x to 1.1.0 won't silently break monitor delivery. After updating, restart your agent so the running watcher picks up the new code.
npx agmsg # install / update
npm i -g agmsg && agmsg install # or this
agmsg on GitHub: https://github.com/fujibee/agmsg
Top comments (0)