claude-code - 💡(How to fix) Fix Feature: Multi-session coordination primitives (cross-session messaging, session registry, compaction-resistant state, shared task board) [2 comments, 3 participants]

Summary

We've been running a multi-agent coordination pattern in Claude Code: one Opus session acting as a project manager (PM), coordinating N worker sessions operating on the same repository. The individual tools exist (Agent, ScheduleWakeup, PushNotification, Tasks, Memory) but they're designed for single-session workflows. The gap is the connective tissue between sessions.

After stress-testing this pattern hard in production, here are the 6 specific friction points — in priority order.

Feature Requests

#1 — Cross-session messaging (highest impact)

Current state: PM and worker sessions coordinate via a shared markdown file. PM writes a directive, worker polls every 15 min, reads it, ACKs by writing back. This is a 2026 version of a shared text file on a network drive.

Request: Allow sessions to SendMessage to OTHER named sessions (not just sub-agents within the same session tree). If sessions could message each other directly, coordination goes from poll-based to event-driven. A 28-min ACK gap caused by a 15-min poll interval disappears entirely.

#2 — Process supervision with exit notification

Current state: A spawned worker process (PID) died silently. Nobody knew for 34 minutes until the next PM poll cycle.

Request: A way for Claude Code to watch a spawned child process and push a notification on exit/crash — including exit code and last stderr lines. The Monitor tool is a step toward this but does not survive compaction. A durable watch-and-notify primitive would eliminate blind spots in long overnight runs.

#3 — Session health / heartbeat registry

Current state: PM spends multiple poll cycles diagnosing whether a worker session is alive, stuck, or dead. There is no isSessionAlive() check, no last-activity timestamp, no session registry.

Request: A session registry for the active project — "here are sessions currently open in this working directory, last activity timestamp." A simple isSessionAlive(sessionId) call would replace all the "is the worker dead or just sleeping?" diagnostic work.

#4 — Compaction-resistant coordination state

Current state: When sessions compact, ScheduleWakeup chains survive but context doesn't. Critical coordination details (gate verdicts, exact task IDs, which bug was fixed, what the worker last reported) get lossy-compressed. After compaction, the session must re-read all plan/status files to reconstruct state.

Request: A structured "coordination state" object that persists through compaction — not memory files, not plan files, but first-class state that the post-compaction session automatically loads. Distinct from the general memory system: scoped to the current session's coordination context, not project-wide knowledge.

#5 — Shared task board across sessions

Current state: Tasks are per-session. PM cannot see worker tasks; workers cannot see PM tasks. We've replaced this with a section in a markdown file that both sides poll and write.

Request: A project-level task board that all sessions sharing the same working directory can read and write. This would replace the shared-markdown-file inbox pattern entirely and make cross-session work visibility a first-class feature.

#6 — run_and_notify for long-running scripts

Current state: Long builds (20-60 min) require 3-5 ScheduleWakeup polls to catch completion. Each poll wakes the session, burns cache, checks a status file, goes back to sleep.

Request: A Bash variant with notify_on_exit=true that survives compaction and pushes a notification (via PushNotification or similar) when the process completes. Eliminates all polling overhead for long builds. The PushNotification tool and Monitor tool exist; the missing piece is durability across compaction.

The Meta-Request

What we're describing is a multi-session project manager pattern: one Opus PM session coordinating N worker sessions on the same repo. The individual tools exist but are designed for single-session use. The connective tissue between sessions is missing.

Cross-session messaging alone (#1) would eliminate an estimated 70% of the coordination friction we've experienced. The other five requests address the remaining 30%.

This pattern is increasingly common as agent workflows scale. Users running overnight pipelines, parallel model training, or any workflow requiring session coordination will hit all of these friction points.

Environment

• Claude Code v2.1.110, Windows 11 Pro x64
• Opus model, high effort, 1-hour prompt cache
• Pattern: 1 PM session + 2-3 worker sessions, same working directory
• Validated over multiple overnight production runs