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, installed as a plugin, these arrive on their own — see Instead: as a plugin. Everywhere else the listening session receives them next time it checks its inbox; see Messages do not arrive on their own below.

Installing

Two ways in. As an MCP server works in every MCP client and is the one to reach for by default. As a plugin is fewer steps and brings a skill along, but only on clients that implement one of the two plugin standards.

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

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.

Claude Desktop

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

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

... View full README on GitHub