chat-across

Englisch | 中文

Ein winziger MCP-Server, der es deinen KI-Coding-Agenten ermöglicht, am selben Projekt als ein Team zu arbeiten – heute Claude Code, Codex und Kimi Code, erweiterbar auf jeden Agenten, der Sitzungen speichert (Vendor hinzufügen sind ~60 Zeilen). Verankere eine Sitzung mit einem einzigen Slash-Befehl an einer benannten Umgebung, und jeder Agent kann lesen, was die anderen tun, direkt aus ihren nativen Dateien, ohne Kopie.

Es passt sich deiner Umgebung und deinem Workflow an – nicht umgekehrt. Installiere einen MCP-Server und arbeite weiterhin genau dort, wo du bereits arbeitest: Codex App, Claude Code / Desktop, Kimi Code, nebeneinander oder einzeln. Keine zentrale GUI, kein neues TUI, keine App, zu der du wechseln musst, nichts zu migrieren. Deine Agenten bleiben deine; sie hören nur auf, einander fremd zu sein.

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

Slash-Befehle

Fünf Befehle decken alles ab. In Claude Code und Kimi Code sind es Slash-Befehle; in Codex tippst du $ und wählst den Skill mit demselben Namen.

Alles, was ein Befehl tut, ist auch in einfacher Sprache erreichbar – „Umgebung project1 löschen", „welche Umgebungen gibt es", „mach weiter, was Codex getan hat" funktionieren alle.

Related MCP server: Cross-Project MCP Server

Was du bekommst

Verankerung – Umgebungen als Treffpunkte

Eine Umgebung ist einfach ein eindeutiger Name (project1, mcp, was auch immer). Sitzungen verankern sich daran; verankerte Sitzungen teilen; unverankerte Sitzungen sind physisch außerhalb – fail-closed, kein Teilen, keine Verschmutzung. Namen sind die Identität: Eine Verbindung mit einem vorhandenen Namen tritt ihr immer bei, sodass es nie zwei project1s gibt.

Kurzberichte – die „Was macht jeder"-Ebene

Jede Sitzung führt einen kompaktierten Arbeits-Kurzbericht auf der Brücke (Ziel / erledigt / wichtige Entscheidungen / als Nächstes), an Ort und Stelle aktualisiert – begrenzt auf 32 KB, eine Zeile pro Sitzung, sodass der Speicher physisch nicht wachsen kann. Kurzberichte tragen eine Byte-Wasserzeichen des Transkripts des Autors, sodass Leser behindBytes sehen: genau, wie viel seit dem Schreiben des Kurzberichts passiert ist. Veraltung ist eine gemessene Zahl, keine Vermutung.

Peers werden nach nativer Sitzungs-UUID identifiziert, nicht nach Vendor – mehrere Sitzungen eines Vendors bleiben unterschiedlich (zwei Claude-Sitze in einer Automatisierungsschleife führen jeweils ihren eigenen Kurzbericht), während dieselbe Sitzung, die sich über einen neu gestarteten MCP-Server wieder verbindet, zu einem Eintrag dedupliziert wird. Übergib sessionUuid (auf jedem Peer angezeigt) an jedes Read-through-Tool, um eine Sitzung präzise anzusprechen.

Natives Read-through – der eigentliche Sinn dieses Projekts

Auf der Brücke wird nichts kopiert. Wenn ein Agent wissen will, was ein Peer getan hat, löst die Brücke auf, wo die eigene App des Peers es bereits speichert, und parst es an Ort und Stelle, bei Bedarf:

Zusammen: Kurzbericht = was sie tun, Tail = die genauen letzten Worte, Speicher = was sie gelernt haben, Anweisungen = die Regeln des Projekts. Ein vollständiger Übernahme-Kontext in einem Connect.

Die Projektidentität wird abgeleitet, nie konfiguriert: Die eigenen Artefakte des Peers tragen sein cwd (Codex session_meta, Claude-Jsonl-Datensätze, Kimi state.json). Funktioniert auch, wenn die Peer-Sitzung geschlossen, abgestürzt oder außerhalb des Kontingents ist – die Brücke liest Dateien, keine Live-Prozesse.

Lebenszyklus – Sichtbarkeit und Bereinigung

Tägliche Nutzung

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

Das ist alles. Der Agent verankert, pusht seinen Kurzbericht, zieht die aller anderen und sagt dir, was die anderen Agenten vorhaben. Dann:

• „Mach weiter, was Codex getan hat" → der Agent zieht Codex' Tail + Speicher + Projektdokumente und nimmt den Faden ab dem letzten Satz auf.

• „Welche Umgebungen gibt es?" → /chat-across-list oder einfach fragen.

• „Starte project1 neu, sauber" → /chat-across-delete project1, dann /chat-across project1.

Neue Sitzung, gleicher Thread

Sitzungen sind auch Peers – einschließlich deiner eigenen älteren. Öffne eine brandneue Sitzung (gleicher oder anderer Vendor), verankere sie an derselben Umgebung, und der Kurzbericht der vorherigen Sitzung kommt mit dem Connect an. Sage „mach weiter, wo meine letzte Sitzung aufgehört hat" und der Agent liest das native Tail dieser Sitzung und nimmt ab dem letzten Satz wieder auf.

Das funktioniert auch, wenn die alte Sitzung geschlossen, abgestürzt oder an ihr Kontextlimit gestoßen ist – die Brücke liest ihre Transkript-Datei, keinen Live-Prozess. Der vendor-native Resume (claude --resume, die Codex-Sitzungsliste) ist für einfache Neustarts desselben Vendors weiterhin die erste Wahl; dies ist der strukturierte Fallback, der auch Kompaktierung, Kontingentwechsel und Vendorwechsel übersteht. Einzige Voraussetzung: Die alte Sitzung hat sich mindestens einmal verankert, während sie lebte.

Installation

Vier Schritte: Paket installieren → in jedem Host registrieren → Slash-Befehlsvorlagen installieren → Hosts neu starten. Funktioniert unter Windows / macOS / Linux (Node ≥ 20), kein Klonen, kein Build.

1. Paket installieren

npm install -g chat-across

Das legt den Befehl chat-across auf deinen PATH und das Paket (Server + Vorlagen) unter dem globalen npm-Verzeichnis ab – npm root -g gibt den genauen Speicherort aus; das Paket liegt unter <diesem Pfad>/chat-across.

2. Server in jedem Host registrieren

Überall derselbe Server, nur das Label unterscheidet sich:

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

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

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

Bevorzugst du keine globale Installation? Verwende stattdessen npx -y chat-across als Befehl in allen drei Konfigurationen. Entwickelst du oder trägst du bei? git clone + npm install + Konfigurationen auf node <repo>/src/server.mjs zeigen lassen.

3. Slash-Befehle installieren

Der Ordner examples/ wird im npm-Paket mitgeliefert. Kopiere seine Vorlagen in das Befehls-/Skill-Verzeichnis jedes Hosts – sie geben jedem Agenten die fünf /chat-across*-Befehle und bringen ihm bei, beim Connect automatisch zu kompaktieren + zu pushen + zu ziehen und seine Sitzungs-UUID zu übergeben.

macOS / Linux:

EX="$(npm root -g)/chat-across/examples"
mkdir -p ~/.claude/commands ~/.kimi-code/commands ~/.codex/skills
cp "$EX"/claude-commands/*.md ~/.claude/commands/
cp "$EX"/claude-commands/*.md ~/.kimi-code/commands/
cp -r "$EX"/codex-skills/* ~/.codex/skills/

Windows (PowerShell):

$ex = Join-Path (npm root -g) 'chat-across\examples'
New-Item -ItemType Directory -Force "$env:USERPROFILE\.claude\commands", "$env:USERPROFILE\.kimi-code\commands", "$env:USERPROFILE\.codex\skills" | Out-Null
Copy-Item "$ex\claude-commands\*.md" "$env:USERPROFILE\.claude\commands\"
Copy-Item "$ex\claude-commands\*.md" "$env:USERPROFILE\.kimi-code\commands\"
Copy-Item "$ex\codex-skills\*" "$env:USERPROFILE\.codex\skills\" -Recurse -Force

4. Neustart und Verifizierung

Starte jede Host-App neu, damit sie die neue MCP-Konfiguration liest, und prüfe dann:

• Claude Code: claude mcp list → chat-across … ✔ Connected

• Codex: codex mcp get chat-across → enabled: true; die Eingabe von $ sollte die chat-across-Skills anbieten

• Kimi: Frage es „welche chat-across-Tools hast du"

Tippe /chat-across test in einem von ihnen ein – created: true bedeutet, dass die Brücke lebt.

Wo alles liegt

Deinstallation = npm uninstall -g chat-across + entfernen Sie die Registrierungen und kopierten Vorlagen + löschen Sie das Datenverzeichnis. Sonst wird nichts weiter geschrieben.

Wie sich das von der bestehenden Landschaft unterscheidet

Tools für kontextübergreifende Agenten gibt es viele – und fast alle schlagen einen von zwei anderen Wegen ein:

• Memory-Layer-Tools (memorix, cass-memory, cross-agent-memory, OpenMemory, …) bauen ihren eigenen Speicher auf: Stop-Hooks oder Ingest-Pipelines fassen Ihre Sitzungen in ihrer Vektor-DB / Playbook zusammen, und Agenten müssen hineinschreiben. Mächtig, aber es ist ein zweites Gehirn, das gepflegt werden will, und es hält Kopien vor, die veralten.

• Live-Messaging-Brücken (AgentBridge über Claude Channels ↔ Codex App Server, …) lassen zwei laufende Sitzungen in Echtzeit miteinander sprechen. Großartig für die gemeinsame Bearbeitung; hilft nicht, wenn die Gegenseite geschlossen, abgestürzt oder über dem Kontingent ist – genau dann, wenn man eine Übernahme braucht.

chat-across schlägt einen dritten Weg ein: kein Speicher, keine Hooks, keine Embeddings, keine Live-Kopplung. Die Hosts persistieren bereits alles – Transkripte, Erinnerungen, Projektdokumente –, also löst die Brücke nur wo auf und parst vor Ort, bei Bedarf. Das Einzige, was sie schreibt, ist eine begrenzte Kurzinfo pro Sitzung. Wenn die Datenbank der Brücke gelöscht wird, geht nichts von Wert verloren.

Designregeln

• Zero-Copy: Gespräche, Erinnerungen und Dokumente werden direkt aus dem jeweiligen Host-Speicher gelesen. Die Brücke speichert nur Zeiger und eine begrenzte Kurzinfo pro Sitzung (max. 32 KB, Bereinigung nach 14 Tagen). Nur lokal, keine Netzwerkverbindung.

• Fail-closed: Eine nicht verankerte Sitzung kann keine Umgebung berühren.

• Nie neu bauen, was der Host bereits hat: kein gemeinsamer Speicherpool, keine Transkriptspiegelung, keine Suchmaschine. Der lesende Agent hat ein Modell; Rohtext reicht.

• Ehrliche Auflösung: Transkriptzeiger sind mit uuid / explicit / heuristic gekennzeichnet, damit Leser wissen, wie sehr sie ihnen vertrauen können.

• Fail-loud: sync/connect überprüfen, ob ihr Commit tatsächlich angekommen ist, bevor sie Erfolg melden, und geben die DB-Datei an, in die sie geschrieben haben; eine beschädigte Datenbank wird unter Quarantäne gestellt (bridge.sqlite.corrupt.<ts>) und beim Start lautstark neu aufgebaut – die Brücke läuft nie verwundet und tut nie so.

Hinzufügen eines Anbieters

Jeder Anbieter umfasst ~60 Zeilen: eine Sitzungswurzel + einen Transkriptzeilenparser + eine cwd-Ableitung + (optional) einen Leser für den Speicher. Die aktuellen drei (Claude Code / Codex / Kimi Code) sind die Vorlage – Agenten wie OpenCode, Hermes, Kiro oder alles MCP-fähige, das Sitzungen auf der Festplatte speichert, können auf dieselbe Weise hinzugefügt werden. Siehe CONTRIBUTING.md für die Adapter-Checkliste und Fixture-Anforderungen.

Warnhinweise

• Claude Code löscht Sitzungstranskripte nach 30 Tagen automatisch (Bereinigung läuft bei jedem Start). Wenn Sie auf langlebige Übernahmen angewiesen sind, erhöhen Sie cleanupPeriodDays in ~/.claude/settings.json – andernfalls kann ein Peer-Zeiger seine Datei überleben.

• Die drei Transkriptformate sind undokumentierte Hersteller-Interna und werden sich ändern; Parser sind von Natur aus versionsgekoppelt (getestet mit Claude Code 2.x, Codex 0.146–0.147, Kimi Code wire v2). PRs willkommen.

• sessionUuid beim Verbinden wird dringend empfohlen – ohne sie fällt die Brücke auf den Abgleich der neuesten aktiven Datei zurück, was bei mehreren gleichzeitigen Sitzungen eines Anbieters zu Fehlzuordnungen führen kann.

• Tails/Erinnerungen durchlaufen einen einfachen Filter zur Schwärzung von Geheimnissen; das ist ein Sicherheitsgurt, keine Garantie.

• Richten Sie CHATACROSS_DATA_DIR unter Windows nicht auf %APPDATA% (oder andere bekannte Ordnerpfade), wenn einer Ihrer Agent-Hosts eine MSIX-verpackte App ist: Die Windows-AppData-Virtualisierung gibt Containerprozessen stillschweigend eine eigene Overlay-Kopie dieser Pfade und spaltet die Brücke in parallele Welten, die nie zusammenfinden. Der Standard (~/.chat-across) ist ausgenommen. In der Praxis auf die harte Tour diagnostiziert.

Lizenz

MIT