Cross-session agent collaboration
Get startedgithub sign-in · private beta
Why this tool?
When building software with AI it is preferable to limit the context of a given agent to the project it is working on. That eliminates the risk of hallucinations and context drift.
But sometimes you need an agent from another project to give you contextual feedback about a specific feature, API, configuration, or strategy. An example might be asking another agent how OAuth was implemented for end-to-end on-behalf-of flow, so that a new agent can integrate similar or identical functionality in its own project without needing to relearn or rediscover the same bugs — burning tokens on something another agent has already solved.
codependence.ai lets the client session prompt a peer and learn from that peer’s memory, context, and repository. You do not need to leave the confines of a project directory to explore another project, or clone another repo to scan its codebase, both of which burn tokens rapidly. Instead, just ask the peer.
Is this safe?
A question is text written on someone else’s machine, and it is read by a Claude Code session that has tools. That is a real risk, so here is exactly what is done about it, and what is not.
- The peer answers read-only. A forked session runs with
Read,GrepandGloband nothing else. It cannot run a command, edit a file, or reach the network, whatever the question asks for. - Answering never touches your live session. The peer is a fork, so a question cannot interrupt, alter, or pollute the work you have open.
- The question arrives labelled as untrusted. It is wrapped in instructions telling the peer it is data, not direction, and not to act on anything inside it.
- Accounts cannot reach each other. Peers and tokens live in per-owner storage that is physically separate, not rows filtered by a query somebody could forget to write.
- A question and its answer are visible to two people: whoever asked, and whoever owns the peer that answered. Nobody else, ever.
- Tokens are per machine, stored only as hashes, and revocable one at a time. Browser sessions rotate, and a stolen cookie replayed after rotation kills the whole session lineage rather than working quietly until it expires.
- The bridge opens no ports. It dials out and holds one connection. Nothing can reach your machine from the internet because of it.
What this does not claim. Read-only tools are a real boundary; the untrusted-data wrapper is a mitigation, not a guarantee. A peer can quote what it reads, so only publish sessions whose repositories you are willing to have quoted back. Today you can only ask your own peers.
Contact
You’re on the list
codependence is in private beta. Nothing else is needed from you — when your account is approved this page becomes your setup screen.
Questions: john@threatsr.us
Choose your handle
It is the first half of every peer you create, so you/api-gateway belongs to you and nobody else can register under it.
Handles are permanent. They are written into every peer id and every question ever asked, so this one cannot be changed later.
Authorise this machine?
A machine is asking to sign in as you. Check the code below matches the one shown in your terminal. If it does not, close this page.
Authorised. Your terminal has the token — you can close this tab.
Waiting for approval
Peers
A peer is a repo on a machine, published with codependence add — nothing is written inside the project itself. The bridge's own files live in ~/.codependence on the machine, once per machine. A peer shows Not connected when no bridge is running there.
Machines
Bridge — for a machine that hosts your peers and answers
questions. codependence login mints one for you, so you rarely
need this.
Client — for a session that asks them. This is the one step 5 wants — codependence connect mints it for you.
Getting started
Run these on the machine where your Claude Code sessions live. You never copy a token — step one puts it there for you.
-
Install the command.
Node 18 or newer. You also need the claude CLI signed in on this machine — that is what actually answers the questions.
npm install -g @codependence/cli
-
Authorise this machine.
Opens this page again to confirm. The token is written straight into the config.
codependence login
-
Publish a project.
Run it inside the repo you want answerable. Repeat for each one — the folder name becomes the peer name.
cd ~/your-project codependence add
-
Start the bridge.
Your peers turn green above. Watch it register and connect — this run is how you confirm it works. It holds the terminal, and ctrl-c stops it.
codependence start
-
Keep it running.
Installs a user service — systemd on Linux, launchd on macOS — so the bridge starts on boot, restarts if it crashes, and survives you closing the terminal. Do this on any machine you reach over SSH, or the peer goes offline when you log out.
codependence service install
Then codependence service status, service logs -f, or service uninstall to stop.
-
Let a session ask.
Run this in whichever project you want to ask from. It mints the token and wires up the MCP server for you — nothing to copy. Restart that session afterwards, then just say: ask how the retry logic works.
cd ~/the-project-that-asks codependence connect
Doing it by hand instead? Mint a Client token above and the page hands you the equivalent command with the token already in it.
-
See who you can ask.
The same roster as above, from the terminal. ● is connected and will answer now; ○ is published but its bridge is not running, so a question waits in the queue.
codependence peers
Removing it from a machine
Revoking a machine above is the server half — it releases the peers that machine held. This is the other half: what it leaves on disk. Paths shown for your machine.
Not sure what a machine is using? codependence --doctor prints every one of these paths for the machine you run it on, which beats trusting this page.