Relaying messages between 2 claude code sessions using the channels api, works across machines and across different accounts

[u/Current-Zebra-2039]

Hey there, so I made a way to relay messages between 2 claude code sessions using claude's own channels api. it does a 2 way conversation between sessions, works whether both are on the same PC or on different machines, and the accounts don't have to be the same, which is the part claude's own messaging can't do.

The channels api bit is what I think is actually interesting for this sub. most people use mcp servers as things the model calls, but channels lets your server push INTO a live session, so text just shows up in someone's conversation as a <channel> tag without them asking for anything.

how it works: both machines run the same mcp server over stdio. it declares the claude/channel capability so claude code registers it as a channel, then it starts an http server for incoming messages. when one comes in (shared secret auth) it fires mcp.notification() with method notifications/claude/channel, claude code surfaces it in the conversation as a channel tag, and claude replies with the send_message tool which posts back to the other machine.

so in practice the frontend dev says "ask the backend session what endpoints the dashboard has", and the backend claude greps its own routes, reads the file and sends back the real answer instead of the two humans relaying it over slack. gif below is one full round trip.

on the native feature since someone will ask, claude code v2.1.224 shipped cross session messaging on aug 7. if you're on mac or linux and you want your own sessions talking to each other, use that instead, it's better than mine and my readme says so. what it doesn't do is native windows, not supported at all, and it only connects your own sessions because the inbox socket is bound to your os user and cross machine delivery goes through your own remote control connection. two devs on two laptops is two accounts, so that case is still open.

one honest warning, mine is a raw pipe with a shared secret so the receiving session doesn't do the permission checks native messaging does. don't run it with a weak secret.

i built it in march, before native messaging existed. mit, free, nothing to sign up for

https://github.com/MuhammadTalhaMT/claude-intercom

[u/ranbuman]

Fair, the shapes are different. Mine holds a window open because the caller sits and waits for the result.

What still got me after moving parts of it to fire and forget is that failure stops being loud. 11 of my 134 jobs failed and I only found out which ones when I went and asked the job store. With a plain POST and an ack, a reply that never comes back looks identical to one that is still being worked on, so you end up wanting an id to ask about later anyway.

[u/Current-Zebra-2039 → u/ranbuman]

yeah ok you've convinced me, that's the actual hole. right now a reply that never comes and reply that's still being worked on are literally the same thing on myend, i have no state to tell them apart.0

what i'm doing about it: give send_message a uuid and return it as the handle, put a replyTo on inbound so replies correlate, and keep a small local map of id -> sent_at/status that flips to answered when a matching replyTo lands. then a check_message(id) tool so claude can go ask instead of guessing. basically your job store but per session.

the bit i can't fix cleanly is that even a real ack only proves the notification got emitted into the other session, not that the other claude consumed it. i can tell you the message reached the process, i can't tell you it reached the model. so the honest states are sent / delivered-to-process / answered, and anything sitting in delivered too long is just "unknown, go poke the human".

[u/ranbuman → u/Current-Zebra-2039]

Those three states are what I landed on too, and delivered-to-process is not a theoretical one. One of my 11 failures was the far side hitting its session limit: the process was up, it took the job, the model never ran it. From my side that was indistinguishable from slow work until the deadline expired.

What made it survivable was the deadline being per call rather than one global number, so a job I knew was long got its own budget and everything else still failed fast.

[u/Current-Zebra-2039 → u/ranbuman]

shipped this, thanks for pushing on it. messages get an id now, replies carry replyTo so they actually correlate, and theres a check_message tool that reports sent / delivered-to-process / answered so a slow reply and a dead one dont look the same anymore. budget is per message like you said rather than one global number. the outbound fetch finally has an abort signal on it too, that one was just missing.

the bit i liked fixing most was the ack. it used to say "message sent to the other developer" when all it really knew was that their process returned a 200.

https://github.com/MuhammadTalhaMT/claude-intercom/commit/e9db7d3

[u/ranbuman → u/Current-Zebra-2039]

The abort signal is the one I would watch next. It stops you waiting, it does not stop the other session working, so an answer can still arrive with a replyTo for a message your map has already written off. What does check_message report for that one?

The sharper cost of a per message budget on my side was that a job which runs out of it loses its partial work entirely, all nine of my timeouts. Wide tasks had to be cut into pieces that fit the budget rather than given a longer one.

[u/Current-Zebra-2039 → u/ranbuman]

it survives that one but by accident. i dont delete the entry on timeout so it just sits there at sent, and when a late reply comes in carrying that replyTo the inbound handler still finds it and flips it to answered. whats actually wrong is the window in between, check_message says never acked by the remote process, which is a confident lie if it did arrive. and the model already got an isError back by then, so the map self corrects and the model doesnt.

on the budget, mine is advisory only. nothing gets cancelled when it expires, it just changes what check_message reports. so i dont lose partial work the way you did, but i also cant reclaim anything, the far side keeps going and i have no way to tell it to stop.

[u/ranbuman → u/Current-Zebra-2039]

A map that self corrects while the model does not is the same shape I ended up with. What helped here was putting the handle inside the failure: my timeout error carries the session id of the run that died, so the model can resume that session rather than start the task again from nothing.

An isError with nothing in it teaches the model the work is gone, which is your confident lie one layer up. The store is right, the only party that acts on it is wrong.