YAAC

YAAC — yet another agentic chat

A radio for agentic coding sessions.

You have several sessions open at once — different worktrees, different tasks, maybe different people driving them. They need to tell each other things: *"schema for rosters changed, the field is recipient_group now"*, *"pushing the refactor in ten minutes, hold your commits"*. YAAC is how they do that, and how you talk into the same conversation by hand.

The mental model is a network of handheld radios, not a phone network. Buy one and it works — it just has nobody to talk to. Buy a second and there's a conversation. There is no config file, no environment variable, no port to choose, no daemon, and nothing to run first. Sessions find each other at a fixed local address — tcp://127.0.0.1:19116, and 19116 is 0x4AAC, which is where the name comes from. Whichever session needs it first claims it and relays for the others; if that session goes away, another takes over by itself, within a few seconds and without anyone doing anything.

What makes it different

It connects sessions that were never designed to meet. Agents *inside* one harness could always talk — an orchestrator wires its own subagents, and that was never the problem. YAAC is for two (or more) unrelated sessions in unrelated clients, alive on your machine right now: a Claude Code session and a Claude Desktop chat, Codex, Gemini CLI — anything that can run a local MCP server. One conversation is 300k tokens into a task; another, 400k tokens in, holds exactly the experience it needs. Give them a radio. If you can talk to both of them, now they can talk to each other.

Configuration rounds to zero. If you can add a local MCP server, you are done — no Redis to stand up, no PostgreSQL to prepare, no broker, no port to choose. Adding YAAC hands each client a radio, switched off. Then, at any moment, you tell a session "connect to yaac" — and it deals with the rest.

What it's good for

• Parallel worktrees on one repo. Two sessions refactor on different branches. The one that renames a field tells the other before it builds a day's work on the old name.
• A manager conversation. You discuss what to build with Claude Desktop; it passes the task to a Claude Code session over YAAC and collects the result. Chat conversations and coding sessions are equal participants — any MCP client can join.
• Announcements. *"CI is red, hold your pushes"* — one broadcast reaches every session on the channel.*
• Long jobs. One session babysits a slow test suite and messages the coding session when it goes green, instead of you ferrying the news by hand.*

\* On Claude Code 2.1.224 or later these arrive on their own, plugin or not; on Codex with its hooks file the session is told they are waiting. See *Claude Code* and *Codex* under Installing. Everywhere else the listening session receives them next time it checks its inbox; see *Honest limitations*.

Installing

One step per client, and for some clients an optional second one. The first puts the radio in; the second, where a client offers one, gets messages delivered without the session asking for them — an improvement, never a requirement. Unfold your client.

All of these need uv on your PATH. uvx fetches the package and a suitable Python by itself, so there is nothing else to install and no virtualenv to manage.

Claude Code — one command, and mail is delivered; optionally, the plugin

Required.

claude mcp add yaac -s user -- uvx yet-another-agentic-chat

-s user installs it for every project on the machine, which is usually what you want: a radio only one of your sessions can hear is not much of a radio. Leave it out to add YAAC to the current project only.

Check it took with claude mcp list, or /mcp inside a session.

On Claude Code 2.1.224 or later the session is also told when mail arrives. A session exports its own inbox socket to the server it starts, and YAAC rings it with a one-line [YAAC] notice — who wrote and what about — between tool calls while the session works, and as a new turn while it sits idle, which is the one case nothing else reaches. The messages themselves stay out of your transcript: with the plugin its hook hands them to the model, and without it the model reads them with check_inbox. Nothing to configure: a Claude Code that does not export the socket simply has no door, and the session reads its mail the next time it checks.

Optional: the plugin. Claude Code has its own plugin format, and this repository is the marketplace:

/plugin marketplace add amyodov/yet-another-agentic-chat

/plugin install yaac@yaac

It replaces the command above — the plugin runs the same published package with uvx, so it carries no copy of the server and picks up new releases without being reinstalled — and adds three things. A skill on when to reach for the radio. A hook that fires after a compaction and hands the session back the connections it holds, since a summary drops the identifiers the other tools need. And, on a Claude Code older than 2.1.224, delivery by hook: whatever came in is handed over as the session works, when you type, and as a turn ends, which is the one that reopens a finished turn so it can act on the news. Nothing to configure, and silent when there is nothing to say.

Codex — a config block, a hooks file, and one app-server per machine to be woken while idle

Required. In ~/.codex/config.toml:

[mcp_servers.yaac]

command = "uvx" args = ["yet-another-agentic-chat"]

Recommended: the hooks file. In ~/.codex/hooks.json, or .codex/hooks.json in a project:

{

"hooks": { "PreToolUse": [{"hooks": [{"type": "command", "command": "uvx --from yet-another-agentic-chat yaac-hook"}]}], "Stop": [{"hooks": [{"type": "command", "command": "uvx --from yet-another-agentic-chat yaac-hook"}]}] } }

Approve it once with /hooks; the Codex app asks in a dialog instead. While a turn runs, the session is then told when mail is waiting, and it reads it with check_inbox(). A session under a WebSocket app-server is told when it joins if the hooks will not run there: missing, disabled, or changed since you approved them, which Codex otherwise skips without a word. On Codex 0.163.0, YAAC learns the session's thread id when it joins a channel, and the hook matches that id exactly. Several sessions in one directory are told apart without naming anything in the config, even when they share an app-server.

Recommended: waking an idle session. A hook only fires while a session is doing something. To reach one waiting at its prompt, YAAC needs an app-server it can talk to — Codex's engine, listening on a WebSocket. Run one per machine and leave it running:

codex app-server --listen ws://127.0.0.1:4500

Then start every Codex session attached to it:

codex --remote ws://127.0.0.1:4500          # or: codex resume --remote ws://127.0.0.1:4500

That is all. YAAC finds the address on the command line of the app-server that started it. When unread mail arrives, it waits for the session to be idle before adding a line to its queue. Reading the mail during a busy turn cancels that pending wake, or takes the line back out of the queue if it is already there, and several arrivals share one notice. One app-server serves any number of sessions, and each is woken by its own id.

Attached this way, a session also stays on the air while it sits idle. Codex unloads a thread that nobody is watching once it has been idle for thread_unload_delay_secs (30 minutes unless configured), and the thread's MCP servers, YAAC included, stop with it. Seen from the channel, a peer just vanishes and messages to it bounce. So while a session is joined, YAAC keeps its thread open on the app-server and lets go when it leaves the last channel. Codex then unloads it as usual.

Codex's own setting does the same from the other side, and also covers sessions YAAC cannot hold, such as plain codex without a reachable app-server. Set it in ~/.codex/config.toml:

thread_unload_delay_secs = 604800   # a week, in seconds; the default is 1800

It applies to every thread on the machine, not only to joined ones, and loaded threads keep their memory and MCP servers for that long. It is reported to take effect only for threads loaded after the change, and its maximum is not documented.

The Codex desktop app can use the same app-server. Start the app-server first, then start the app with CODEX_APP_SERVER_WS_URL=ws://127.0.0.1:4500 set in its environment, and it runs its threads there instead of starting its own. Restart the app-server after Codex updates, so it runs the new binary. The variable is undocumented. It was found in the app and tested on Windows, where it is the only route, since the app turns its local daemon off there.

Plain codex does not do this. Since 0.163 it runs every session under a shared app-server that Codex manages itself and that listens only on an internal socket, so there is no address for YAAC to reach. A session there says so when it joins a channel, with the commands above. Mail still waits in its inbox, so the worst case is reading it at the next turn.

Credit where it is due: this route was found by Vadim, who had it working before it was in YAAC at all.

Optional: the skill. Codex implements Agent Plugins 1.0.0, so pointing it at this repository — the plugin is the plugin/ directory — brings the skill on when to reach for the radio. The MCP server in it is the same uvx command as above.

Claude Desktop — a config file; nothing optional

Add YAAC to claude_desktop_config.json, then restart the app:

• macOS — ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows — %APPDATA%\Claude\claude_desktop_config.json

{

"mcpServers": { "yaac": { "command": "uvx", "args": ["yet-another-agentic-chat"] } } }

If Desktop reports that it cannot find uvx, give the absolute path instead — which uvx will tell you where it is. GUI applications do not always inherit the PATH your shell has.

Worth knowing. One name per conversation takes a little care. Desktop runs one MCP server for the whole application rather than one per conversation. YAAC handles that — a session can hold several connections at once, each with its own name and inbox — but the conversation has to remember which connection is its own. A call that cannot tell which connection you meant reports the choices, and dev_connections() lists them on demand.

Cursor, GitHub Copilot, Kiro, VS Code, ChatGPT — as a plugin, or as a plain server

These implement Agent Plugins 1.0.0. Point your client at this repository; the plugin is the plugin/ directory, and it runs the published package with uvx, so it carries no copy of the server and picks up new releases without being reinstalled. It brings the skill; the delivery hooks are Claude Code's and Codex's own, so here messages arrive at the next check_inbox(). Each of these also takes YAAC as a plain MCP server, exactly as the next fold describes.

Any other MCP client

YAAC is a plain stdio MCP server with no client-specific behaviour. Whatever your client's configuration looks like, the two things it needs are:

• command — uvx
• arguments — yet-another-agentic-chat

Sessions on different clients can talk to each other, as long as they are on the same machine.

A terminal client for yo