Jesse-njx/dsh-crosstalk

dsh-crosstalk

Cross-session messaging for DSH. Any session on the machine can list and message any other — Claude Code-style horizontal messaging, no daemon.

dsh-crosstalk is a DeepSeek Harness bundle. Every session running the bundle publishes a heartbeat to a local registry under ~/.dsh/crosstalk/ (files + atomic rename, no daemon — if two sessions can see the same home directory, they can message). Each session gets a stable name (<repo-or-cwd-slug>-<adjective>, e.g. dsh-cowork-amber) plus a durable ref id; any session can list the live ones and send a message that arrives in the target as a clearly-labeled turn — [message from session dsh-cowork-amber (/Users/me/projects/dsh-cowork)] — with the sender's name riding along, so replying is just send_message back.

Why this shape

DSH ships send_message and list_agents, but strictly hierarchical: a parent messages its own background subagents. Sibling sessions — two DSH sessions in different repos on the same machine — cannot see or message each other. Multi-session workflows (one session per repo, a coordinator farming work out, a routine pinging a live session, a chatnode human-in-the-loop peer) all need the missing primitive: horizontal messaging. dsh-crosstalk copies Claude Code's model — ListAgents shows every live local session; SendMessage addresses any of them by name — onto DSH's existing tool names, so the tools you already know gain a peers scope and peer addressing without a second vocabulary.

How it works

1. Identity — at start, the session derives <slug>-<adjective> from its working directory plus a process-unique ref (ct-…). Same cwd, two sessions → different adjectives, distinct names; the ref disambiguates and is what inbox paths use.
2. Registry — one heartbeat JSON file per live session under <home>/registry/<ref>.json (name, ref, pid, cwd, status, startedAt, heartbeatAt, uid, inbox). Refreshed on a timer; entries with no beat for 2× the interval are shown as dead and garbage-collected (heartbeat file + orphan inbox removed).
3. Tools — extend, don't duplicate:
   • list_agents gains scope: peers (other live sessions on this machine: name, status, cwd, last activity) and scope: all (descendants + peers). The stock children/descendants scopes are delegated to the captured stock definition.
   • send_message accepts a peer name or ref in to alongside subagent ids, with an optional summary (5–10 word recap shown in the target UI).
   • The stock tools stay registered; this bundle shadows them per agent (scoped registrations are reversible Cordis effects), so unloading cleanly restores stock behavior exactly.
4. Delivery — the message is one JSON file appended to the target's inbox (<home>/inbox/<ref>/), written atomically (temp file + rename), so a crash mid-write is never observed as a partial message. The target's watcher polls its inbox and injects each accepted message into the live session via followup: an idle target wakes for a turn; a busy target receives it at the next turn boundary. Delivery is best-effort — list_agents status is not a delivery promise.
5. Injection — the turn is labeled [message from session <name> (<cwd>)] and carries a crosstalk source (form: relay), so the append-only log records provenance by construction and the DSH UI renders it as a labeled relay card — never as user text. The system prompt tells the model these are requests from a peer agent, not instructions from the user.