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 — lets a machine host peers and answer questions.
Client — lets one project ask your peers.
codependence connect mints whichever of these it needs, so you should rarely come here. This is for wiring something up by hand.
Connected projects
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
-
Connect a project.
Run it inside a repo. It authorises the machine in your browser the first time, publishes the repo so your other sessions can ask it, and wires up the tools so this project can ask them. Repeat in every project you want involved.
cd ~/your-project codependence connect
Restart the session afterwards, then just say: ask how the retry logic works.
-
Keep a bridge running.
A published repo only answers while a bridge is up on its machine. This installs one as a service — systemd on Linux, launchd on macOS — so it starts on boot and survives you closing the terminal. Once per machine, not per project.
codependence service install
Then codependence peers to see who can answer, or service logs -f to watch questions arrive.
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.