documentation

crosscode keeps several checkouts of one repository in sync in real time. you edit a file, and everyone on the same branch has it within seconds. the only interruption is a same-line conflict, which goes to your own coding agent rather than to a crosscode ui, because there isn't one.

documentation pages

policies

privacy policy · terms · cookies · subprocessors · data processing agreement · copyright and dmca · eu dsa contact · accessibility · support

what crosscode is

everyone works in their own ordinary git checkout. a small background daemon per checkout notices an edit once it has settled, sends that one file to whoever is on the same branch, and applies their edits to your working tree the same way. most of the time you are on different files and nothing is ever shown to you.

when you both changed the same lines of the same file, that is the one case that genuinely needs a decision. it goes to your own coding agent with all three sides of the merge, and the agent fixes it. crosscode never judges a change, classifies risk, or reviews code.

git stays the durable history and publishing layer. only uncommitted working-tree files are in scope: commits, branches, the index, the stash, and remotes are never touched, and nothing crosscode does pushes. stop running it and your repository is unchanged.

what works today

below is what is built and tested. current limitations covers the boundaries crosscode draws on purpose, and it is worth reading alongside this.

the merge core

• a single ref, refs/crosscode/shadow, holding the last state both sides agreed on. it never moves HEAD and never appears in git log
• the apply rule: write silently when your copy matches the shadow and the sender built from it, otherwise a 3-way merge, and only surface a conflict when that merge does not come out clean
• proven against disjoint files, same-file disjoint hunks, same-file same lines, delete versus edit, rename, binary, offline-then-reconnect, and three peers converging
• binaries are never merged, so concurrent binary edits are always a conflict. a conflicted path is quarantined until it is resolved

the daemon

• one per checkout, started by crosscode start, restarted automatically if it crashes
• watches tracked files with a hard denylist, and debounces about 300ms per file so an edit is sent once it settles
• never writes a file you or your agent touched in the last ten seconds
• pauses during a rebase, merge, or bisect, then resyncs. a plain commit or pull on the branch you are already on is a different case: it rebases the agreed state onto the new HEAD, keeps your uncommitted edits, and tells your agent when a teammate's commit means you should pull
• reconnects and catches up from its cursor, or resyncs from full content when the cursor is too old
• binds to loopback only, with a mode-0600 connection descriptor in the git directory

the service

• a store-and-forward relay on supabase-hosted postgresql, with row level security from the first migration
• six tables carry the product, plus device_codes for pending sign-ins and terms_acceptances for accepted terms versions. presence is in memory in the websocket gateway, not a table
• sequence numbers, fan-out, cursor-based catch-up, and about 7 days of replayable history
• it does not merge, classify, or inspect anything

your tools

• five cli commands: start, invite, join, status, stop
• four mcp tools and one skill, with conflicts attached to every response
• any mcp-capable agent or editor: claude code, codex cli, opencode, cursor, vs code, gemini cli. there is no plugin to install
• one npm package, crosscode-cli, shipping both crosscode and crosscode-mcp

see current limitations for what sits outside that scope on purpose.