chat-across

One tiny MCP server that lets your AI coding agents work on the same project as one team — Claude Code, Codex, and Kimi Code today, extensible to any agent that persists sessions (adding a vendor is ~60 lines). Anchor a session to a named environment with a single slash command, and every agent can read what the others are doing, straight from their native files, zero-copy.

It adapts to your environment and workflow — not the other way around. Install one MCP server and keep working exactly where you already work: Codex App, Claude Code / Desktop, Kimi Code, side by side or one at a time. No centralized GUI, no new TUI, no app to switch to, nothing to migrate. Your agents stay yours; they just stop being strangers to each other.

Claude Code ─┐
Codex App  ──┼──►  chat-across bridge (stdio MCP)  ──►  one small SQLite (pointers + briefs only)
Kimi Code  ──┘          │
                        └─ reads peers' NATIVE session / memory / docs in place — nothing duplicated

What you get

Together: brief = what they're doing, tail = the exact last words, memory = what they've learned, instructions = the project's rules. A full takeover context in one connect.

Project identity is derived, never configured: the peer's own artifacts carry its cwd (Codex session_meta, Claude jsonl records, Kimi state.json).

Related MCP server: Cross-Project MCP Server

Install

Straight from npm — no cloning, works on Windows / macOS / Linux (Node ≥ 20):

npm install -g chat-across

Register the same server in every host, only the label differs:

# Claude Code
claude mcp add chat-across -s user --env CHATACROSS_HOST_LABEL=claude-code -- chat-across

# ~/.codex/config.toml
[mcp_servers.chat-across]
command = "chat-across"
env = { CHATACROSS_HOST_LABEL = "codex-app" }

// ~/.kimi-code/mcp.json
{ "mcpServers": { "chat-across": {
  "command": "chat-across",
  "env": { "CHATACROSS_HOST_LABEL": "kimi-code" } } } }

Prefer not to install globally? npx -y chat-across works as the command in all three configs. Developing or contributing? git clone + npm install + point the configs at node <repo>/src/server.mjs.

Then drop the command/skill templates from examples/ into ~/.claude/commands/, ~/.codex/skills/, and ~/.kimi-code/commands/ — they teach each agent to auto-compact + push + pull on connect and to pass its session UUID.

Daily use

/chat-across myproject        # Claude / Kimi  (Codex: type $ and pick chat-across)

That's it. The agent anchors, pushes its brief, pulls everyone else's, and tells you what the other agents are up to. Say "continue what Codex was doing" and it pulls the tail + memory + docs and picks up from the last sentence. /chat-across-sync refreshes manually; /chat-across-disconnect leaves.

Fresh session, same thread

Sessions are peers too — including your own older ones. Open a brand-new session (same vendor or a different one), anchor to the same environment, and the previous session's brief arrives with the connect. Say "continue where my last session left off" and the agent reads that session's native tail and resumes from the last sentence.

This works even if the old session is closed, crashed, or hit its context limit — the bridge reads its transcript file, not a live process. Vendor-native resume (claude --resume, the Codex session list) is still the first choice for plain same-vendor restarts; this is the structured fallback that also survives compaction, quota switches, and vendor hops. Only requirement: the old session anchored at least once while it was alive.

How this differs from the existing field

Cross-agent context tools are a crowded space — and they almost all take one of two other roads:

• Memory-layer tools (memorix, cass-memory, cross-agent-memory, OpenMemory, …) build their own store: stop hooks or ingest pipelines summarize your sessions into their vector DB / playbook, and agents must write into it. Powerful, but it's a second brain to maintain, and it holds copies that go stale.

• Live-messaging bridges (AgentBridge over Claude Channels ↔ Codex App Server, …) let two running sessions talk in real time. Great for co-editing; doesn't help when the peer session is closed, crashed, or out of quota — which is exactly when you need a takeover.

chat-across takes a third road: no store, no hooks, no embeddings, no live coupling. The hosts already persist everything — transcripts, memories, project docs — so the bridge just resolves where and parses in place, on demand. The only thing it writes is one bounded brief per session. If the bridge's DB is deleted, nothing of value is lost.

Design rules

• Zero-copy: conversations, memories, and docs are read in place from each host's own storage. The bridge stores only pointers and one bounded brief per session (32KB cap, 14-day pruning). Local-only, no network.

• Fail-closed: an unanchored session cannot touch any environment.

• Never rebuild what the host already has: no shared memory bank, no transcript mirroring, no search engine. The reading agent has a model; raw text is enough.

• Honest resolution: transcript pointers are labeled uuid / explicit / heuristic so readers know how much to trust them.

Adding a vendor

Each vendor is ~60 lines: a session root + a transcript line parser + a cwd deriver + (optionally) a memory-store reader. The current three (Claude Code / Codex / Kimi Code) are the template — agents like OpenCode, Hermes, Kiro, or anything MCP-capable that persists sessions to disk can be added the same way. See CONTRIBUTING.md for the adapter checklist and fixture requirements.

Caveats

• Claude Code auto-deletes session transcripts after 30 days (cleanup runs on every launch). If you rely on long-lived takeover, raise cleanupPeriodDays in ~/.claude/settings.json — otherwise a peer pointer can outlive its file.

• The three transcript formats are undocumented vendor internals and will drift; parsers are version-coupled by nature (tested against Claude Code 2.x, Codex 0.146–0.147, Kimi Code wire v2). PRs welcome.

• sessionUuid at connect is strongly recommended — without it the bridge falls back to newest-active-file matching, which can mis-map when several sessions of one vendor run at once.

• Tails/memories pass a basic secret-redaction filter; it is a seatbelt, not a guarantee.

License

MIT