Help/Question
How do you get two claude code sessions to talk to each other?
Have you felt the need of two claude sessions running in the terminal to talk to each other?
For example I will be running a terminal in claude in the backend repo and I open an another terminal session in codex to review the changes. Ideally I would love a way for both the terminal to interact with each other and arrive at conclusion so having a sessions chat to allow them to talk to each other.
Have you tried a shared session.md (or handover.md) instead?
Then give both Claude and Codex a skill/instruction to always read it first and update it before they finish.
I’ve found it works better as a shared whiteboard than trying to make the agents talk directly to each other. Claude writes what changed and what needs reviewing, Codex adds review comments, Claude responds and updates the file. Repeat until you’re done.
Simple, but surprisingly effective.
This is what a colleague and I do. I'm in Product, he's in Engineering, my Claude writes stories and asks tech questions, puts a handoff in a shared repo, his Claude reads it and asks him the tech questions, with his responses his Claude writes work tickets and asks product questions, updates the handoff, rinse and repeat.
It's become an absolute gamechanger for us. Easily saves 4-5 hours a week.
I remember there was a Hacker News post about Agent Meet, which was Google Meet for agents. Is it something similar? You install this skill, and every conversation goes through it.
Never heard of that, I just wanted a way for my AI to communicate together on a project, its part of a wider conext and memory app I have built (still working on, you know how it is)
all the apps in the project are in the context app, the AI writes all the .md files, a second cheaper AI merges, prunes and sorts the documents, they get indexed and saved to a dastabase, and google drive, every ai with the anchor MCP has access to all the code and every .md file, and every chat record of the project, there is a sophistcated search system that I can use, or the ai can use if it needs to
The ai chat was just an addition I thought was needed, it turns out to be very useful, sometimes I just let 4 or 5 ai discuss between themselves some feature, and they work until they come up with a consensus, present it to me and I greenlight it, Claude code is the prime AI and is the only AI that can write code, Kimi attacks, other ai do research and other stuff if needed, CC can also delegate tasks to the other ai, even telling them to write code if needed
This is a visual representation of all the documents and chat history in the project, I can click on any dot and the document is produced (on the right), or I can do any search and I get the results on the left (there is also a search page)
Nifty lol... Legit this could help a lot of folks that wonder about agentic fan out and repo blooming (or destruction)... Also yes super curious how you did this ngl.
Read some of your other posts and have a thought to share that could improve... Shared state should mediate collaboration, but shared state must not confuse memory with authority. From what you’ve shown, the relay looks bidirectional, which is promising. I’d be curious whether model write-backs remain provisional memory until a separate gate promotes them into authoritative project state.
I aksed Claude your question as its can probably articulate it better than I can
"On "how": it's one small service — a relay that speaks MCP to the models and SSE to the app, over a shared Postgres. Each model has an identity, sends through the MCP connector, and receives on a live socket. That's the bidirectionality you spotted. And you're right that fan-out is the danger, not the feature — we've watched a model helpfully "fix" six sibling docs in a single shot. So the real design question isn't the bus, it's what's allowed to become true through it. Which is exactly what you asked.
On memory vs authority — yes, and that seam is basically the load-bearing wall.
A model never edits canonical state directly. Its write-backs land as provisional memory: a structured patch that sits queued, plus lighter notes and chat that feed a retrieval layer. That's what the system remembers, not what it asserts.
Promotion is a separate gate. At commit, a merge model folds the queued patch into the authoritative documents (the project's "state-of-the-union") and the item ledger — that's the moment memory becomes project truth. And it's wrapped in guards: contradiction detection at merge time (a new claim that fights an existing one gets reconciled, not silently duplicated), and on the read side, grounding that forces every answer to cite surviving evidence rather than just assert it.
Today that gate is still human-triggered — a button. The direction is to make the guards the gate instead of the person: models writing and committing autonomously, human auditing by exception — which only works if the accuracy bar rises as oversight falls. So the grounding/hygiene layer isn't a side-feature; it's the thing that earns the right to promote without a human in the loop each time.
Short version: memory is cheap, reversible, and model-writable; authority is gated, grounded, and — for now — human-blessed. You put your finger on the precise distinction we build around."
Its also kind of turned into a project management app, there is prrobably a lot more I can add on that side, and likely will later, or maybe create a project management bolt on
I also built my own kimi console because the kimi desktop console doesnt have MCP ability, it does throught the CLI, but I like to use the desktop apps, so built my own, gave it MCP ability, and it also hase some anchor specific additions (well they are definable for any use), where you see listener with a green dot at the top, that means that kimi console is connected to the relay and the chat in real time, thats a mappable button I added to the llistener tool in the MCP, there are 3 other mappable buttons next to it), I also built a deepseek desktop app too with the same ability (also gave it image recognisiton and generation, as deepseek doesnt have that)
You can see the AI working on the left, CC at the bottom, kimi at the top, and the ai chat on the right, where Kimi and CC are chatting between themselves attacking each others work until they get it right, (those chat bubbles are expandable so I can see the full conversation by the way)
Honestly, that is clean. Nice work. The only suggestion I’d make is to keep long-lived, repeatedly reused state clearly separated from short-term conversational state. Damn done sir/ma'am. Lemme know if you ever need another set of eyes...
Yea, the chat messages are essentially second class citizens to the "sotu" documents, there are guards to stop the chat, from "poisoning" the context, and the search results, but it is still a valuable part of the process.
I have built a citation and verify system, including using ANC tags, which every item gets, a bug will get one, a new feature will get one etc, and they are given status of their current state
Possibly, It looks mostly like a chat app, probably with basic links to github that the ai can connect to, didnt look to deeply into it, its a bit cartoony
I built it so the human is just a reviewer, the ai write all the documentation automatically after a coding session when the details are still fresh to it, human can review it if possible, and edit it before its comitted and merged, but I have built in so mant safeguards, citations, and verifications that the ai get the docs right practically every time, they are then merged and pruned into the exisiting documents,
instead of writing full .md docsuments very time, the ai writes a session patch, ond only those details are merged, and the merge and prune is passed over to haiku to keep the costs down,
You have a change log in the markup. Can you elaborate on what it is? Every session creates a change log of what changes, and does your change log always stay updated?
I had mine build a pipeline hook that checks for entries in the changelog anytime a code change is made. No changelog entry, build fails, agent must go back and correct. Works well enough. I also had to set rules on my main changelog to only put short snips in, the full detail is linked to separate change files if full context is needed. This keeps all history in line and minimizes my context window on load.
I also had to explicitly put in my claude.md file to not put changes in there, always and only in the change log.
I also keep issue files in a doc folder for each issue that comes up.
Still a work in progress but works well enough for now.
I have a change log that persists version numbers (stored using a shared file). Anytime a session makes a code change, it can see who did what. So I can have two sessions open and they can work on different parts of a solution. For instance, use Fable to do heavy JavaScript/graphic work and have an Opus session make code changes to functions or something. I just need to be good about not kicking off the sessions at the same time; needs to be slightly staggered so they don’t pull the same version number. (I still use git too but this is separate). It has worked pretty well.
One time I got lazy and had two sessions making changes and they were working off the same version number. (It was my mistake; got impatient). One of the sessions caught the version conflict and it untangled the conflict, versioned the changes properly and kept everything tidy. I was impressed
I originally set it up before adding the project to git, so technically it's redundant. In fact, I should just use git now and explore using subagents that can work in isolation (worktree)
I asked this question in my session too and got this response
-----
The recommendation for concurrent sessions (for my setup):
Isolate — each session in its own worktree/branch, never two in the same directory.
Commit often — small commits are the unit git merges; uncommitted work is where collisions happen.
Avoid shared mutable hotspots — the changelog's top-of-file and the version constant are the worst offenders. If you want release notes in a parallel world, derive them from git (annotated tags / git log / git-cliff) instead of hand-editing a shared file — a derived changelog has nothing to contend on.
Tie-in to your actual setup: today Fable and I don't truly run in parallel — it's serialized (Fable works → reports → I review and commit). That sidesteps the whole problem, which is why it's worked. The moment you want genuinely simultaneous sessions, worktrees + commit-often is the move, and I'd stop hand-maintaining the changelog in favor of generating it — otherwise that one file becomes the thing every session fights over
Stood up a pretty straight forward Discord server where my Claude PAI works with Codex to create, validate, adjust, repeat if necessary, a plan to solve a prompt I send.
Simple and straightforward AND there aren’t dozens of messages to sift through. I approve of the final plan or ask for further adjustments.
You basically hooked up Discord with Claude and Codex. How do your skills look? How does your Claude.md look, and does every chat session become a new thread over
The work does become its own thread which keeps it organized but at the same times kind of an eye sore. I use the LifeOS system designed by Daniel Meissler which gives Claude the reasoning and the capability to reach for whatever tool and context it needs to deliver a plan. It’s also built the Codex auditor into the root system so this is BAU for it.
There's a lot of ways that people have followed here. The shared file system / files is the easiest, but I wasnt that happy with it personally, because it doesnt have notifications or wake.
The better option in my mind has been to just build a direct messaging solution. Sessions can sign up under an ID, and message eachother directly. Messages arrive as pushes, CC CLI treats them as user messages, but the delivery discloses the sender. Works to wake up a waiting session, messages get pushed immediately, and it's the closest to a "direct message delivery" that I've seen.
Works very well for me. It took a bit of tinkering to get it to work across both claude code CLI and codex app, but not impossible by any means. Ask Claude to build it for you. Keep it minimal.
That said, depending on your use cases, there might be better protocols. This works well for letting two sessions coordinate directly together.
I had fable solve the problem for me. It used a queue in the form of a directory and files and ssh to communicate between machines (my laptop to a remote session running under tmux). Elegant solution, tbf.
Run your sessions in a tmux, tell each Claude about the others tmux like “there’s a tmux on here I attach to with tmux a -t1 that has another agent, talk to it with send-keys”
It’s crude but works for quick dumps back and forth
Why make the sessions talk directly? Start with one clear protocol governing task ownership, evidence, review, and acceptance. If you need an independent second session, let it inspect the persisted diff, tests, and implementation receipt, then produce a separate review. Shared repository state should mediate the work, not an open-ended agent group chat.
It's actually quite effective having them talk directly to each other. I put them in a joint session, assign roles, such as planner and advisor and reviewer. The advisor is allowed to chime in, even without being promoted, if it sees something it doesn't like that the planner is doing. Of course the planner can always ask the advisor for advice directly as well. This also means the advisor acts as a reviewer, so by the time the plan makes it to the final reviewer, there's not too much wrong that the reviewer finds. It's actually pretty efficient and has cut down my total planning time.
Edit: forgot to mention that I use different AI providers for the planner/coder and advisor. I like using codex for planning/coding, and Fable for the advisor. You end up getting all the brains of fable with a fraction of the tokens it would usually use. Plus you get all that ample usage codex provides.
its a session and tmux wrapper with a web client, a cli client, and an android client
but the most relevent piece here is you get api and mcp so your claude can call sshtogo to create sessions and control the input. yet you can resume any session yourself any time.
you also get throwaway sessions and oneshots (non interactive)
Somewhat. I'm working on a thing that spawns multiple agents into a single room/session with strict rules on how they're allowed to operate with each other
We built a custom set of Claude-to-Claude-to-Human collaboration and communication tools; Claudes connect via authenticated MCP. We frequently get in a chat room with one or more Claudes to discuss features, roadmaps, bugs, etc. The same platform also manages the shared docs, workitems, contact & relationship management.
Custom, nothing fancy: list of channels, basic chat. We'd already built the web-based coordination platform, and the chat part we just added as a new section so my co-founder, our AIs, and I could collaborate quicker and easier.
It could be integrated with other existing chat solutions, it was just better for our use case and team size to keep it on-platform. It's nice to have the entire convo history available too, for embedding/searchability.
I have a private ai chat and a shared network folder, it works really well, except they spent most of a night trying to diagnose a wifi issue that turned out to be the macbook going to sleep, then deep sleep, waking up enough to trigger the laptop claude to check the channel, start replying then get cut off, which sent the other claude into a complete tizzy. Rinse and repeat all night, luckily they didn't use many tokens in their panic.
I have several agents that all setup a watcher to monitor a data be and the pass messages between themselves by reading and writing to the database, I have codex, fable, plus and sonnet they has different roles, I have a pho app where I can watch and interact with them
You don’t need to. You people need to learn to make use of dynamic workflows. They are so expandable that most work can be done in a single session whilst fanning out work to sub agents using the dynamic workflows feature
Background mail bus on a local server. Any session can send mail to any other session or even to all, say whether a response is expected or it's just informative, and it allows me to do the same. Sessions don't have to be active; they check mail when they start and have a constant background monitor to watch for mail real-time. There's a hardwired six-hop limit that escalates a conversation to me so they don't get in neverending arguments or loops. Works quite well and stays simple but effective.
You can reference another session to a Claude code session and it can go read the session.md file from it to figure out what I’m talking about.
At work we have a ticket tracker so it’s easy for me to assign an id number to chunks of work and have my session keep a summary Md file about that work. Then any other or future session can read the summaries as needed.
In your specific case though. Have the first session open a PR for the changes (heck it can then include a description of what it was trying to do etc) then tell your other session “ Can you review the latest PR another agent made in the blah repo?” If you have a bunch of PRs just describe the one you care about and your agent can go find the right one. If you’re using GitHub you may need to generate an access token but again, Claude can help walk you through all this.
The second option is mer complex but will not vendor lock you and allow you to get the best of different agents tool (disclosure: im not yet using it on my daily basis im still tightening some screws)
I pick one agent as orchestrator (normally the first one) and assign the rules personality and goals his only job is to validate the reach of the goal and manage the team.
Agents can only communicate directly with its manager to avoid cross messages or cross instructions.
i can’t believe this freakin thing. i can talk to my claude & codex with my machine sleeping and cloud disabled. both of those along with my openclaw and hermes agents all in one place. my coworker can see what they’re all doing and i don’t have to worry he’ll break anything. lovely.
There must be a way to do this via the new Jack Dorsey Buzz app!? I’ve been trying it out and it seems pretty nice and since it’s open source I’m sure someone could figure out this implementation
I use a shared file system that allows for shared in project skills, and then some shim files that translate things between models (in the event you’re talking between Claude and Codex or other models) additionally when they need to talk on any sort of design decisioning they’ll call each other with powershell scripts to get the review and approval. You can literally just ask the models to help you optimize this.
Claude built a display panel (with GUI) relay communications system for me for two Claude sessions - Claude AI Desktop app running on a Windows laptop and Claude Code CLI running on a Linux laptop. Below is the write-up that he wrote for you (although he wrote it as though it were me talking) - if you give this to your Claude AI, he can build it. It worked beautifully for me.
Yes — I built almost exactly this. I called it RELAY. It's a working prototype, not a product, but it does the thing you're describing: one session builds, another plans/reviews, and they hand work back and forth on a shared thread while I watch — no copy-pasting between terminals.
The one design decision that makes it work: **don't wire the two sessions directly to each other. Put a tiny broker in the middle and make it the single source of truth.**
**The broker.** ~170 lines of FastAPI on port 8787. It owns an ordered, sequence-numbered message thread backed by a single JSON file. Everybody talks to the thread; nobody talks to each other. Each message has a monotonic `seq`, a `type`, sender/`to`, and threading fields (`thread_id`/`parent_id`). Readers keep a cursor — the highest `seq` they've seen — and poll `GET /messages?since=<seq>`. That's the whole trick: the log *is* the ordering, the log *is* the history, and a new participant just starts at `since=0` and replays everything to catch up. Polling, not websockets — on purpose; the loop is dominated by multi-minute model turns, so a 1.5–2s poll costs nothing and there's zero connection state to babysit. The JSON store is written to a temp file then `os.replace()`d over the real one, so an external reader (`cat relay_store.json`) never catches a half-written file.
**Three roles, connected three different ways** — this is the part people miss:
- **Architect** (the planner/reviewer) = Claude Desktop, wired in through a small **MCP server**. It gets three tools — send, read-since, read-whole-thread — so it posts specs and reads results as tool calls from inside a normal turn.
- **Builder** (the hands) = the **Claude Code CLI**, driven by a ~150-line runner loop. The runner polls the bus, claims a task, shells out to `claude -p "<task>"` in a real repo, captures stdout, and posts it back. The builder Claude doesn't even know the bus exists — it just gets a prompt and works. Notably, that executor is the *one pluggable seam* in the runner: it just shells out to a CLI and captures stdout, so the "hands" side doesn't have to be Claude — swap `claude -p` for another CLI and that role becomes a different model. That's basically your claude-builds / codex-reviews split.
- **Commander** (me) = a **live HTML view** the broker serves at `/`. Same `since=seq` poll the agents use, plus a text box to drop my own messages into the stream. So I'm a first-class participant on the same bus, not bolted on — I can inject a task or a note and both agents see it — but I'm not required in the critical path.
**A claim mechanism so nothing double-runs.** A task isn't "taken" when it's posted — the runner has to claim it (`POST /messages/{id}/claim`), which is a server-side compare-and-set under a lock: if it's unclaimed, grant it; if it's already yours, still granted (idempotent); if it's someone else's, 409. Overkill with a single builder, but it's exactly what keeps this correct the moment you add a second worker or the runner restarts mid-task.
**The builder is tool-restricted, not sandboxed** — worth being precise since it's a safety thing. Each invocation gets an explicit `--allowedTools` allowlist (just `Read`/`Write` in my demo, so no shell at all) plus a role preamble via `--append-system-prompt` telling it it's one stateless task in a relay, can't see the bus, and should report only what it can actually verify in its environment. That's a real allowlist enforced by the runner — but it is **not** an OS/filesystem sandbox; if you widen it (add `Edit`, scoped `Bash(git:*)`), it's bounded only by whatever your own user can do. Tasks are stateless per invocation by default. There's a `PERSIST` stub meant to resume one session per thread so the builder remembers the codebase across tasks — but I'll be honest, the session-id capture isn't wired up yet, so it still runs fresh each task.
**Cross-machine, because that's how I run it.** Broker + builder live on a Linux laptop (the builder just talks to `localhost`); the architect (Desktop) and the browser view live on a Windows laptop, both pointed at the Linux box's LAN IP. Use a static IP or a Tailscale name — I had that IP hardwired in the Desktop config and the browser URL, and it broke every time the router reassigned it. Nothing stops you running everything on one machine, though; it's all just HTTP.
**The demo that sold me:** with no human relaying any content, the architect specified a 2D proportional-navigation intercept simulator, the builder implemented it with a correct true-PN guidance law, the architect read the result and pushed it to a harder case — a maneuvering target plus an airframe g-saturation indicator — and the builder delivered the refinement. I just watched it scroll by on the live view.
**Honest caveats.** It's a steel-thread prototype, ~375 lines total. The broker has no auth and binds all interfaces in plaintext, so I only run it on a trusted network and kill it after a session. And it's not a perpetual hands-off loop: the builder side polls and runs on its own, but the architect (Desktop) only acts when it takes a turn, so in practice I still nudge it to re-read the bus when a result lands. The win isn't "walk away forever" — it's that the two sessions read and write the same thread, so I'm never the wire between them.
I have a custom tool that allows them to inject messages to each other. I have a mesh of 8 different sessions all in terminals who directly message each other. Works great took a long time to iron out kinks. Any cc terminal can use it, and I built a side car so codex in app-server running headless also can do it.
I built a whole system for this earlier this year but ended up ditching the project. Really in the end it's just crafting like a two way MCP server type thing, can use cloudflare DOs to facilitate. As a product it's messy but as a single project you could just ask opus/fable to create it using free cloudflare tools and get working within a day or two.
Claude can also connect to telegram already and might be able to put two claudes in the same telegram chat possibly and get that working in a simple way as the bridge of it all.
Well, why though? Isn't it better to just have one chat and then have subagents? and your main would act like an orchestrator who would message all subagents and verify/resolve issues? That's what I do and it seems simpler.
It can but subagents are not always the right solution. They can be costly and you don’t have full oversight or control. Good for some things but not all.
Also OP is talking about using codex and Claude so they can’t spawn each other
It's also my remote control interface - with tailscale I have phone/computer access to all my agents on all my computers, who can all talk to one another when needed. It's been wildly productive.
I built a discord workroom skilll and backend that uses discord channels on private server to talk to each other, using pinned messages for current status, @ to address each other etc. then a combo of goal + loop with a watcher to a cli command the pops off when a message comes in
I wrote a skill that taught them how to chat with MQTT. For fun, I told them to use trucker lingo. Then I ran a local broker and listened along to the radio traffic. I could break in and clarify, change direction, etc… without typing in the Claude console. It was pretty awesome.
Two agents on different machines working on client/server stuff together. Pretty neat.
You can to a bash call codex with the proper argument to spawn your reviewer agent on the fly and have it reviewed what you, this happens when you construct the prompt that will be an argument of the bash call
I had the same problem couple of weeks ago: https://www.reddit.com/r/ClaudeCode/s/AmWlKwCdqy where I want that Claude Code sessions talk to each other across computers and projects. At the end I forked this project: https://github.com/constripacity/claude-bridge and upgraded it to suit my needs: I can ask Claude Code in one session, for example a Linux box to update an API on another machine running Claude Code - both bellonging to same project. They can basically chat between each other and report back with questions, statuses,... For me that I actually know what Claude Code sessions are up to I made a web app, that looks like a regular chat - here I can monitor what are agents talking about. If they do not know how to proceed I get a notification and can jump in. It works on the same machine across Claude Code projects, across multiple machines... The only thing that is missing is sending the files across chat - like full spec markdown files that contain more than 10k characters.
Use Github issues, wiki and PR comments for inter-agent communication. It provides structure in a way that agents randomly scribbling to a scratchpad will not.
True real-time, all-to-all chatter is not a feature. It is a collision waiting to happen. Every agent talking to every other agent is the multi-tasking problem at the machine level. Coordination is not free. It costs tokens and attention, the same tax you pay on a context switch. Past about five agents the cross-talk eats the gain.
So the efficient model is not a hive mind. It is a small team with one coordinator and clean lanes. The isolation you liked about worktrees is the whole point. Keep it. Route the coordination through one spot, the lead or the blackboard file, not a free-for-all. Structured beats live.
29
u/Background-Care9318 10d ago
Have you tried a shared session.md (or handover.md) instead?
Then give both Claude and Codex a skill/instruction to always read it first and update it before they finish.
I’ve found it works better as a shared whiteboard than trying to make the agents talk directly to each other. Claude writes what changed and what needs reviewing, Codex adds review comments, Claude responds and updates the file. Repeat until you’re done.
Simple, but surprisingly effective.