Crosstalk

English | 한국어

Discuss a topic with Claude and Codex side by side in Ghostty, or invite Antigravity (agy) as a peer. Ask from either CLI. Crosstalk reuses the other AI's pane or opens a native split, sends the question, and returns the response. No tmux required.

Crosstalk connects existing interactive AI CLIs. Start from Codex with $crosstalk <topic> or Claude Code with /crosstalk <topic>. Each participant analyzes independently, and the caller compares the answers — consensus or respectful disagreement, without forcing agreement.

Ghostty is the main getting-started path for Claude ↔ Codex discussion. The existing cmux backend remains available for advanced workflows. Support differs by backend:

See the Ghostty verification record for the actual checks and their limits. This checkout includes the Ghostty integration. Update older marketplace installations before following the quick start.

• Visible discussion: watch Claude and Codex work in neighboring Ghostty panes, starting from either CLI.
• Reuse existing CLI accounts: Crosstalk does not introduce a separate model API integration.
• Automatic peer preparation: launch the other CLI in the current directory when no labelled peer exists in the tab; wait for its startup acknowledgement before sending a task.
• Independent answers: each participant receives the user's original topic.
• Durable mailbox: Ghostty requests and replies are stored in SQLite. send, receive, and reply handle IDs, receipt state, and reply notifications; AIs no longer manage per-message MD files or ping commands.
• Explicit verdicts: the bridge parses [AGREE] and [RESPECT_DISAGREE] markers to guide subsequent rounds.
• Quick opinions: ask lets each AI answer in its own pane without callbacks or aggregation.
• Advanced cmux workflows: co-work in git worktrees, PR review, and Antigravity peers remain available through cmux.

Antigravity (agy) is a standalone download. It can participate as a peer in Ghostty mailbox discussions or legacy cmux runs. Install and authenticate the CLIs you plan to use.

Crosstalk supports English and Korean command UI. During /crosstalk:install, choose the interface language:

• English
• Korean

The setting is stored in:

~/.claude/crosstalk/config.json

{
  "active_rules": "default",
  "active_persona": "default",
  "language": "en"
}

Use "language": "ko" for Korean. Built-in rules and personas are installed in both languages:

~/.claude/crosstalk/rules/{en,ko}/
~/.claude/crosstalk/personas/{en,ko}/

In Claude Code:

/plugin marketplace add dongsik93/crosstalk
/plugin install crosstalk@crosstalk

Then run the one-time setup:

/crosstalk:install

This installs:

• ~/.claude/scripts/crosstalk and a ~/.local/bin/crosstalk symlink (if that name is free)
• ~/.claude/crosstalk/mailbox.md
• ~/.claude/scripts/crosstalk_bridge.sh
• ~/.claude/scripts/crosstalk_ghostty.sh
• ~/.claude/commands/crosstalk.md
• ~/.codex/skills/crosstalk/
• built-in rules and personas under ~/.claude/crosstalk/

After installing the Ghostty-enabled version of Crosstalk, open your project in Ghostty and run either CLI normally. Existing sessions can stay open.

Starting from Codex:

$crosstalk Should this project use Compose or XML? Discuss it with Claude.

Starting from Claude Code:

/crosstalk Should this project use Compose or XML?

Claude and Codex are the default pair. To use Antigravity, name it explicitly:

$crosstalk Review this design with agy.
/crosstalk Review this design with agy.

Crosstalk reuses a labelled peer in the same tab or creates a right split and starts the other CLI in the current directory. Finish any first-use login/trust prompts there. Once startup is acknowledged, the question is delivered and completion callbacks return to the caller.

Ghostty tab
├── Codex  ← questions and responses →  Claude

For quick independent opinions, use $crosstalk ask <question> or /crosstalk:ask <question>. Each AI answers in its own pane; no combined result is produced.

To check status without launching a peer, run $crosstalk or /crosstalk without a topic. The readiness check shows the backend, caller, and peers. If the caller cannot be identified, report that error and preserve the topic for $crosstalk resume or /crosstalk:resume.

Crosstalk does not currently set a model or effort level. Reused panes keep their session settings; newly launched CLIs use their own defaults. Codex settings are not copied to Claude, or vice versa. There is no Crosstalk-specific model/effort override yet.

When the Crosstalk skill or slash command needs to create a new Ghostty peer, it offers two choices:

Auto-approval applies to all tools in that session, not just mailbox commands. The choice is not saved globally. Existing peers keep their current permissions and are reused without another choice. Changing an existing peer's mode requires an explicit user decision to restart it; the bridge will not do so automatically.

Direct bridge commands do not display a choice. Without the flag, they keep CLI defaults:

~/.claude/scripts/crosstalk_bridge.sh ensure-peer codex agy

After explicitly choosing auto-approval for a new peer:

~/.claude/scripts/crosstalk_bridge.sh ensure-peer claude codex --auto-approve
~/.claude/scripts/crosstalk_bridge.sh ensure-peer codex claude --auto-approve
~/.claude/scripts/crosstalk_bridge.sh ensure-peer codex agy --auto-approve

An existing matching peer causes --auto-approve to be rejected. Omit the flag to reuse it; a timeout or permission prompt is not permission to relaunch with broader access.

Ask Codex or Claude to discuss a topic with agy, or prepare and contact it directly:

~/.claude/scripts/crosstalk_bridge.sh ensure-peer codex agy
crosstalk send agy "Review this approach" --summary "Reviewing the proposed approach"

From Claude, use ensure-peer claude agy. agy and antigravity resolve to the same peer kind. The launcher uses agy --prompt-interactive and preserves the caller PATH. The common permission choice above applies to agy too. Finish any login, project, or tool-approval prompts in the new pane. On timeout, reuse the pending pane instead of launching another copy.

New agy panes learn the mailbox workflow at startup. For an existing manually bound agy pane, ask it to read ~/.claude/crosstalk/mailbox.md once before sending summary notifications. agy uses the same ID-less receive and reply --summary flow; the cmux /crosstalk-peer ... RUN_ID=... handler remains for legacy runs. Discussion callers remain Claude or Codex.

Terminal detection checks the caller's process ancestry as well as Ghostty environment variables; a missing TERM_PROGRAM no longer defaults to cmux. A stale socket alone is not treated as a running terminal.

Run /crosstalk:setup once from any pane and label every pane (including the caller). The other CLIs in the same directory then find their own pane by CLI kind on their first call, so setup does not need to be repeated in each pane. Codex identifies itself by its session ID (CODEX_THREAD_ID), because its tool commands run in a daemon owned by the first Codex instance and the process tree points at the wrong pane. Resuming a Codex session in a new pane re-resolves automatically if the old pane is closed.

If the pane still cannot be identified (for example two CLIs of the same kind in one directory, or a resumed Codex session while its old pane is still open), the error lists candidate IDs and titles. In the intended CLI, run ~/.claude/scripts/crosstalk_bridge.sh bind ghostty:<UUID> once, or /crosstalk:setup --surface ghostty:<UUID> from Claude. The selection is remembered for that CLI process; do not run the bind command from a different CLI on its behalf.

If startup times out, finish login/trust prompts in the existing peer pane and retry. Crosstalk keeps track of that pending startup so a retry does not create a duplicate.

The bridge's first connection to an existing CLI needs a unique working directory among Ghostty terminals, or a unique pane of the caller's CLI kind among the labelled ones. That binding is then tied to the caller process identity. Ambiguous directories fail instead of guessing the focused terminal; set CROSSTALK_SURFACE_ID=ghostty:<UUID> explicitly for those bridge calls. Newly launched peers inherit their exact ID (Codex binds its session to the pane at startup). IDs and directories can be inspected with:

osascript -e 'tell application "Ghostty" to get {id, name, working directory} of every terminal'

Manual bridge commands:

~/.claude/scripts/crosstalk_bridge.sh self
~/.claude/scripts/crosstalk_bridge.sh ensure-peer codex claude
# From a Claude caller: ensure-peer claude codex

Ghostty supports analyze, ask, and replies from Claude/Codex callers, with Claude, Codex, or Antigravity as peers. Advanced cowork/review flows remain cmux-oriented. Ghostty 1.3 does not expose screen contents through AppleScript, so capture, screen transport, and footer-based readiness are unavailable. Unknown existing panes need an explicit bridge label <ID> claude|codex|antigravity|shell.

Long messages and responses stay in the local SQLite mailbox; Ghostty displays a one-sentence question or reply summary; protocol IDs and commands are not included in the notification. Only receive acknowledges receipt. No daemon, socket server, or clipboard is used. macOS may ask for Automation permission to control Ghostty. Existing file/ping runs still work for compatibility.

Run python3 tests/test_bridge.py and python3 tests/test_mailbox.py for isolated terminal and mailbox checks.

The existing demo and hero image show the cmux workflow. They are not recordings of the new Ghostty integration.

Run these from a Codex pane after /crosstalk:install has installed ~/.codex/skills/crosstalk/.

These exist for manual control or recovery — you typically don't need them.

All supported participants use the same mailbox commands:

crosstalk send claude "What do you think of this design?" --summary "Reviewing the proposed design"
crosstalk receive
crosstalk reply <MESSAGE_ID> "My analysis..." --summary "The design needs an explicit invalidation rule"

Use codex as the destination when Claude is the caller. Readiness prepares the peer first with bridge ensure-peer; send requires exactly one labelled peer in the current tab. If ~/.local/bin is not in PATH, use ~/.claude/scripts/crosstalk directly. Long bodies can be piped via --stdin instead of passed as command arguments.

1. Send stores the body in ~/.claude/crosstalk/mailbox.sqlite3, then notifies the peer using its exact Ghostty terminal ID.
2. Receive without an ID atomically claims the next pending message for this terminal in insertion order and returns its full body and IDs as JSON. Duplicate notifications return actionable: false; they do not instruct the AI to process the request twice.
3. Reply stores and links the answer, marks the request replied, and notifies the original caller. The AI does not write response files or call ping.
4. Compare: the caller reads the reply, compares it against its own view, and summarizes or sends a follow-up with send <peer> --thread <ROOT_ID>. The tool enforces a maximum of 10 request/reply rounds per thread.

request: pending → received → replied
                              └─ reply message: pending → received

The tool extracts explicit verdict markers from replies. A marker describes the peer's position; the caller still compares both views before claiming consensus. With send --mode ask, the answer is stored and printed in the peer pane, but no reply notification is sent to the caller.

The sending AI provides --summary; no extra model call is made. Missing summaries fall back to a body excerpt. Notifications are limited to 160 preview characters and remain display-only: the receiving AI drains its pending messages one at a time and replies using IDs returned by SQLite, never by matching preview text. It displays the actual questions and answers after reading them. Old ID-bearing notifications still work. CLI-controlled tool traces may remain visible.

If notification fails, the tool returns the saved message ID and exits nonzero. Use retry with that ID instead of creating another request. Repeating reply with the same body returns the existing reply; a different body cannot overwrite it.

The database survives process restarts. It is private to the local user. It does not sandbox that user's AI processes. Both sides must use the same CROSSTALK_CONFIG_DIR if overriding the default. Terminal IDs remain the delivery addresses: closing a pane requires manual recovery; the tool does not silently redirect its messages to another pane. A busy CLI or permission dialog can still block wake-up. There is no unattended retry daemon.

cmux workflows and existing RUN_ID conversations continue using /tmp/crosstalk/run-* with preambles/, rounds/, assignments/, responses/, and completion ping. The old low-level crosstalk_bridge.sh send <surface> <text> remains available; it is separate from the new mailbox crosstalk send <peer> <body> command.

Use cmux for co-work and PR review. These workflows have not yet been ported to Ghostty; Antigravity mailbox discussions are supported.

For PR review, run /crosstalk:review <PR>. The experimental --deep variant checks out the PR branch and attempts to restore the previous branch afterward.

analyze is for opinions. cowork is for delivery. Give each peer an assignment and a goal. Each runs its own /goal slash command in its CLI and works until it considers the goal met.

/crosstalk:cowork "claude=Repository layer, codex=ViewModel layer, goal=mail search feature shipping with passing tests"

Flow:

1. Crosstalk parses the assignment, asks once whether to isolate work in git worktrees (recommended), and falls back to --no-worktree for shared-tree work.
2. Fan-out: each peer's slice + /goal "<goal>" + final report instructions are written to assignments/<agent>.md; cmux receives only [crosstalk] cowork-task <agent> RUN_ID=....
3. Each peer runs its own /goal. The peer's CLI keeps stop blocked until it judges the goal met — Crosstalk doesn't second-guess that judgment.
4. Time cap: default 1 hour. On timeout (or on /crosstalk:cowork-stop), bridge sends /goal clear + a termination notice to every peer via cmux.
5. Result aggregation: the moderator reads each peer's report + their git log inside the worktree and writes cowork-summary.md. Worktree handling is up to the user — keep (default), merge, or drop.

/tmp/crosstalk/run-<RUN_ID>/
  manifest.json
  responses/
    claude-r01.md          # each peer's work report
    codex-r01.md
  assignments/
    claude.md              # each peer's work prompt
    codex.md
  cowork-summary.md        # moderator's rolled-up summary

/tmp/crosstalk/worktrees/run-<RUN_ID>/
  claude/                  # git worktree on branch cowork/<RUN_ID>-claude
  codex/                   # git worktree on branch cowork/<RUN_ID>-codex

Why delegate goal judgment to the peer's /goal? It keeps Crosstalk thin: peers know their own model's signal best, and Crosstalk doesn't have to invent a verifier. The cap + cowork-stop are the only safety nets — no LLM judging "looks done."

MVP scope: peers don't see each other's progress (no live cross-check). They run in parallel; the moderator stitches results at the end. Cross-check between peers is on the roadmap.

Optional. Default analyze runs with no persona assignment and minimal rules. Pass a preset only when you want to shape the discussion.

Built-in rule presets:

Built-in persona presets:

Example:

/crosstalk:analyze --rules debate --persona critic-builder Should we merge this PR?

Custom presets live here (each rule/persona file is loaded into the preamble verbatim — no compression):

~/.claude/crosstalk/rules/{en,ko}/
~/.claude/crosstalk/personas/{en,ko}/

• macOS only: the terminal backends currently require macOS.
• cmux CLI UI detection can change: cmux launch readiness and auto-detection use CLI footer patterns. If detection fails, run /crosstalk:setup and label panes manually.
• No hard sandbox: Crosstalk coordinates local CLI processes; it does not sandbox them.
• Legacy file runs require bridge ping: completion is event-based — if a peer never pings, the moderator stays idle. You can manually call bridge ping <RUN_ID> <agent> <round> from any pane to unblock.
• AI may ignore transport instructions: cmux opt-in --transport file/screen modes treat this as a protocol error with retry/skip/stop choices.
• Deep PR review is experimental: it touches the current git worktree through checkout/stash/restore.
• Callbacks depend on CLI input handling: Ghostty two-way transport has been checked locally, but a busy CLI or permission dialog may delay or prevent input processing. Check mailbox receipt state before assuming the peer started work; legacy ping does not acknowledge each earlier trigger.
• Antigravity caller is not supported: Antigravity (agy) participates as a peer only; runs must be started from Claude or Codex.

• Ghostty support for advanced cowork/review workflows
• Per-peer model and effort selection
• Unattended delivery recovery and explicit rebinding after pane closure
• Antigravity moderator mode
• Additional CLI adapters
• tmux and zellij support
• Better troubleshooting docs
• More robust launch detection
• Public examples of real PR review sessions

Issues and pull requests are welcome. Good first contributions include:

• updating CLI footer detection patterns
• adding rules or persona presets
• improving install and troubleshooting docs
• testing against different Codex/Antigravity/Claude CLI versions
• exploring tmux or zellij adapters

Crosstalk is released under the MIT License.