Claude Code Multi-Session Control Desk

A control desk for parallel Claude Code sessions that assigns work, routes handoffs, and flags conflicts before agents edit the same code.

When developers run several Claude Code sessions against the same repository, they assign each one a role and worktree first: changing an API, adding regression tests, or investigating a production issue. The control desk reads each session’s declared goal, current branch, and files being touched, bringing work that would otherwise be scattered across terminals into one visible task board.

When one session finishes an API change, the related testing session automatically receives a change summary, commit ID, and the behavior to verify. If a session depends on an unfinished change, it can send a request scoped to the relevant files and functions, rather than making the developer copy an entire chat transcript. The developer only confirms priorities in the control desk; other messages are routed to the right session according to dependencies.

If two agents are about to edit the same section of a file, the later one is temporarily held. The page clearly shows who holds editing rights, when they are expected to be released, and whether the other agent can work on tests or another module first. After each task is complete, test results, change notes, and unresolved assumptions are collected in a merge-ready output area for item-by-item review, so the developer does not have to guess which code is trustworthy across multiple terminals.

The first release supports Claude Code, Git worktrees, and file-level conflict warnings, addressing the chaos of one developer directing several sessions in parallel. It does not automatically merge team conflicts or replace code review; the developer retains control of the final merge button.

Why now

On August 8, 2026, the official cross-session messaging documentation entered an HN discussion; as recorded on August 9, it had 50 points, 26 comments, and ranked 18th. S1 Native handoffs lower the barrier to transferring work between sessions, making task dependencies, change ownership, and conflict warnings the next problems to solve. S2

Target user

Developers maintaining medium-to-large repositories on their own, as well as technical leads on small teams. When rushing to fix production incidents, changing APIs across layers, or adding regressions, they start several sessions at once. What is scarce is visibility into dependencies and ownership of changes. As terminals multiply, manual handoffs and checking each session’s status slow merge decisions.

Minimal entry point

A local daemon first calls `claude agents --json` to obtain session directories, names, and states. S3 A `SessionStart` hook registers each session’s role, branch, worktree, and task goal. A `PreToolUse` hook reads file paths from editing tools and pauses writes with exit code 2 when it detects an active lease. S4 On completion, it reads Git commits and test output to create reviewable deliverables. Session summaries are sent through `SendMessage` or the session socket. S2 Version one uses file-level leases only, with no automatic merging or semantic conflict detection.

Punching above its weight

Recruit early users from the multi-session practitioners in this HN discussion, inviting people who use tmux, handoff files, or homegrown coordinators to try it. S1 Provide a reproducible repository where an API session and a testing session must hand off a dependency. Demonstrate fewer terminal switches and earlier warnings when two sessions change the same file. Distribute it as a Claude Code plugin or local command so developers can validate it directly in an existing repository.

Competitors & gaps

Claude Code Agent View, Cross-Session Messaging, and WorktreesGoogle
Claude Code’s native feature set already covers much of the surface-level need. Agent view centralizes background sessions and shows working, blocked, and completed states. It can also dispatch tasks, reply to sessions, view results, and link worktrees and pull requests. S3 Cross-session messaging lets separate sessions exchange plain-text summaries. S2 However, ordinary terminal sessions must be moved to the background to fully appear in Agent view. Public documentation does not describe cross-session file leases, function-scope negotiation, or a dependency board. Handoffs still rely primarily on messages and session summaries, without a unified structure for merge-ready outputs. The control desk’s opening is to orchestrate native capabilities into a reviewable engineering workflow.
tmux, Git Worktrees, and Handoff FilesGoogle
A common practice is to use tmux panes, with each session in a separate Git worktree. In the HN discussion, one developer also described a homegrown setup using a memory tree, handoff files, and a coordinator to reduce repeated context. S1 This approach is transparent, scriptable, and does not depend on another desktop app. Worktrees isolate immediate writes, but merely defer some conflicts until merge time. Developers must still maintain roles, dependencies, and completion criteria themselves. Handoff files can go stale and cannot confirm whether the recipient has acted on them. Scripts usually compare only files or commits, making it hard to express temporary ownership of a section of code. A control desk could turn these conventions into states, reminders, and traceable negotiation records.

How it makes money

Keep the core local dashboard free and open source. Charge a monthly per-developer subscription for history, cross-device access, custom coordination rules, and team permissions.

The case against

Claude Code already has Agent view, worktrees, and cross-session messaging, so a basic dashboard could be absorbed by native features. S2S3 File-level locks may also wrongly serialize changes that could be completed independently. Moving to function-level locking introduces false negatives from syntax parsing, renames, and generated files. When hooks block a write, they must give the session enough context; otherwise, the agent may repeatedly retry. Cross-session messaging is also constrained by system, provider, and permission settings. S2 If false blocks become frequent, developers will bypass the control desk and its coordination state will quickly become inaccurate.

Evidence and sources

4 checkable sources cited
Discussion snapshot· Hacker News
Claude Code cross-session coordination
Points
50
Comments
26
Rank at capture
#18
Posted
Snapshot time
snapshot August 9, 2026, 00:33 UTC
View the Hacker News threadRead the original article
Sources
S1

On August 8, 2026, Claude Code’s cross-session messaging documentation entered a Hacker News discussion; the input snapshot from August 9, 2026 recorded 50 points, 26 comments, and rank 18. In the comments, one developer described a homegrown setup using tmux, a memory tree, handoff files, and a coordinator.

Hacker NewsAugust 8, 2026news.ycombinator.com/item
S2

Claude Code v2.1.224 or later supports cross-session messaging on the same machine. Claude uses ListAgents to discover sessions and SendMessage to send plain text; local sessions also provide a socket and CLAUDE_CODE_MESSAGING_SOCKET. The capability works on macOS and Linux, not native Windows, and is unavailable from some cloud providers.

S3

Agent view can dispatch and manage background sessions from one terminal interface, showing working, blocked, completed, and pull-request states. `claude agents --json` can output session directories, types, states, names, and identifiers. Background sessions enter isolated Git worktrees before editing.

S4

Claude Code hooks receive session_id, transcript_path, cwd, tool name, and tool input. A PreToolUse hook can block a tool call before execution; exit code 2 blocks that tool. SessionStart can inject context and set a session title.

Telegram channel