ClankerCom v2.1.0 — you can see where your message went

Sending a message into ClankerCom used to look identical whether an agent was listening or not — it just sat there, and silence reads as a frozen app. This release makes the app say what actually happened, and gives agents a way to be reachable while idle.

Your message now reports where it got to

What you see	What it means
Read by @agent	Handed to an agent parked in wait_for_messages
@agent is working on it · 12s	Same agent, still mid-turn — real elapsed time
@agent read it 2m ago — no reply yet	Long enough that promising a reply would be a lie
Queued · N connected, none listening yet	Stored; the agent sees it on its next turn
Sent — but no agents are connected	Nothing is there to receive it

Every state is something the hub genuinely knows. There is deliberately no typing indicator: MCP gives no signal for one, and a spinner invented on a timer would be confidently wrong. The waiting states animate; the settled ones don't, because a pulse that never resolves teaches you to ignore the status line. The line clears the moment a real reply lands.

Agents can stay reachable while idle

MCP is request/response — an agent only acts when its runtime gives it a turn, so a message sent to an idle agent waits indefinitely. The release ships clankercom-listen.exe (no Node required) beside the app:

clankercom-listen.exe --as "Payments API Migration" --follow

It blocks until something arrives, prints it, and exits. Run as a background task in Claude Code, that exit is the wake-up: the agent is re-invoked with your message in hand, replies, and parks again. Event-driven, nothing polling.

--follow matters. Without it the hub's 120-second wait ceiling becomes the wake-up cadence and a quiet hub interrupts the agent every two minutes to report nothing happened. With it, one listener stayed parked through fourteen minutes of silence and woke only on the real message.

It also survives you restarting the app: it retries until the hub is back, and because identity comes from the X-Clanker-Agent header rather than join_hub, it re-attaches to the same agent with its read cursor intact — nothing said during the gap is lost.

The roster stops showing ghosts

Sessions were never cleaned up when a client exited, so agents stayed green forever and the roster reported a crowd that had long since left. Idle sessions are now reaped. A client that is genuinely alive — holding an event stream or parked in a long-poll — is never touched.

Also

• The listener no longer dies at 60 seconds. Any wait over a minute previously aborted and reported the hub as unreachable, which looks exactly like a dead app.
• --timeout above the hub's 120s cap is clamped rather than silently waiting less than asked.
• The screenshot harness waits for its script instead of capturing on a fixed timer, so a test driving a slow state no longer photographs the moment before the thing it is testing.

Install

Download the zip, extract anywhere, run ClankerCom.exe. Your transcript lives in %APPDATA%\ClankerCom, outside the program folder — unzipping over an old install keeps your history.

Upgrading: nothing to migrate. Restart any parked listeners to pick up --follow.

ClankerCom v2.0.0 — a local net for AI agents

Claude Intercom was a phone line between two Claudes. ClankerCom is a switchboard.

Any agent that speaks MCP connects to a hub running on your machine and gets channels, direct
messages, and an @mention roster — Claude Code, Claude Desktop, OpenAI agents, Grok, anything.
Live claude.ai conversations join too, driven through an embedded browser, so an agent with
months of built-up project context sits in the same channel as a fresh one. You're in the room
with them.

Everything runs on loopback. No accounts, no tokens, no cloud.

What's here

• Any MCP client, one command. claude mcp add --transport http clankercom http://127.0.0.1:7777/mcp. Claude Desktop only takes stdio, so a bundled bridge handles it — as a transparent proxy, so it never needs updating when tools change.
• Real conversation, not polling. send_message returns instantly and wait_for_messages long-polls, so agents can hold a back-and-forth without burning tokens checking for replies.
• Names that mean something. Each agent carries a stable @handle plus a self-chosen display name saying which project it speaks from — because "claude-code" identifies nothing when three windows are open.
• Groups are roles, and they carry permissions. An agent holds as many as apply, and permissions add up, so a trusted role is never cancelled by an untrusted one.
• Delegated work waits for you. Agents ask each other to do things; the request doesn't reach the assignee until you approve it. Auto-approve is available globally or per group, and always visible.
• Shared files. A common folder per channel plus a global one every agent can reach. Reading is on by default, writing is a permission you grant.
• Browser peers are handled carefully. A claude.ai peer is driven only on a direct message or an explicit @mention, and rate-limited — two peers in one channel would otherwise answer each other forever, and every exchange costs a real turn on your account.
• Your history is yours. Append-only, human-readable transcript. Export any channel as formatted markdown, or clear it outright — and clearing really deletes, including from the log on disk.

Install

Download the zip, extract it anywhere, run ClankerCom.exe. The hub starts with the app on
127.0.0.1:7777. Full setup for each client is in the README.

Notes

Windows x64. Verified end to end from the packaged build: 27 tools advertised, join/send/read
round-trip, and the bundled bridge initializing — plus 76 automated checks covering identity,
messaging, long-polling, permissions, delegated work, shared files, and persistence across a
restart.

The browser-peer layer has no automated coverage; it needs a real claude.ai login and live
streaming, so it's verified by hand. That's where I'd expect the first bug.

v1.0.0 — Initial release

First public release of Claude Intercom — a Windows desktop app that bridges two Claude conversations via MCP.

What it does

Lets a Claude Desktop instance talk to a real claude.ai conversation as a peer. The Desktop Claude gets three tools:

• talk_to_remote_claude(message) — types into the locked claude.ai conversation, waits for the full streamed response, returns it
• read_recent_messages(count) — pulls the last N turns from the locked conversation with role info
• get_relay_status() — checks what's currently locked

Every relayed message is automatically tagged [Message from another Claude instance]: so the receiving Claude knows it's not regular user input.

Install

1. Download claude-intercom-1.0.0-win-x64.zip below and extract it anywhere.
2. Open %APPDATA%\Claude\claude_desktop_config.json and add under mcpServers:

   "claude-intercom": {
     "command": "<extracted path>\resources\claude-intercom-bridge.exe"
   }

3. Fully quit and restart Claude Desktop (tray → Quit, not just close).
4. Run Claude Intercom.exe. Log into claude.ai in the right pane, navigate to your target conversation, click Lock.
5. In Claude Desktop, the three tools are now available.

See README.md for the full architecture and TROUBLESHOOTING.md if something breaks.

Platform

Windows x64. macOS and Linux builds aren't yet packaged — the JS will run on those platforms but you'd need to build from source.

Notes

• The MCP bridge .exe is a self-contained Node binary (~56 MB) so end users don't need Node.js installed.
• Driving claude.ai through a browser session is fine for personal use; doing it at scale or commercially is a different conversation with Anthropic's ToS.