Bidirectional session communication and multi-machine support via Channels

[amahpour]

Problem

The Command Center currently has one-way communication — hooks push session events to the dashboard, but there's no way to send prompts or instructions back to running Claude Code sessions. Additionally, the architecture is limited to a single machine.

Original problem (terminal launch)

The previous "New Session" implementation that launched sessions via tmux had a fundamental architectural issue:

Session ID mismatch: The Command Center creates a tmux session with a short UUID (e.g., 35ef0abc), but Claude Code assigns its own internal session UUID (e.g., 82e3f6e7-36db-4435-b1b5-a1cfe24133e1) when it starts. Hook events fire with Claude's UUID, not ours. This creates two DB records for the same logical session — one from our launch, one from hooks — causing:

• Duplicate session cards on the dashboard
• "Session not found" errors when navigating back to a launched session
• No way to map our tmux ID to Claude's session ID

Additional complication: Claude Code shows an interactive trust dialog on first launch in a directory that requires manual Enter to proceed.

Broader problem

• No way to send prompts/instructions to running sessions from the dashboard
• Architecture is tightly coupled to local tmux — single machine only
• No path to orchestrating sessions across multiple developer machines

Desired Behavior

1. Dashboard can send prompts to any connected Claude Code session
2. Claude Code can reply back to the dashboard
3. Sessions on multiple machines can all report to a single dashboard
4. Clicking a session card shows a chat-like interface (not a terminal)
5. Optionally provide an initial prompt from the dashboard

Proposed Solution: Claude Code Channels

Use Claude Code's Channels system (research preview, v2.1.80+) to build a custom MCP-based channel server that bridges the dashboard and running sessions. See the comment below for the detailed proposal.

Context

• Hooks already handle monitoring (SessionStart, PreToolUse, PostToolUse, Stop, etc.)
• The channel would add the "write back" capability
• Channels are MCP servers that Claude Code spawns as subprocesses
• They communicate over stdio (MCP protocol) and can expose HTTP endpoints
• This supersedes the tmux-based approach entirely

[amahpour]

Proposal: Custom Channel Server for Bidirectional Communication

Architecture

                         ┌──────────────────┐
                         │    Dashboard      │
                         │  (existing UI)    │
                         └───────┬──────────┘
                                 │
                    ┌────────────┼────────────┐
                    │            │             │
               ┌────▼───┐  ┌────▼───┐   ┌────▼───┐
               │Machine A│  │Machine B│   │Machine C│
               └────┬───┘  └────┬───┘   └────┬───┘
                    │            │             │
              ┌─────▼─────┐ ┌───▼──────┐ ┌───▼──────┐
              │ Channel   │ │ Channel  │ │ Channel  │
              │ Server    │ │ Server   │ │ Server   │
              └─────┬─────┘ └───┬──────┘ └───┬──────┘
                    │            │             │
              ┌─────▼─────┐ ┌───▼──────┐ ┌───▼──────┐
              │ Claude    │ │ Claude   │ │ Claude   │
              │ Code      │ │ Code     │ │ Code     │
              └───────────┘ └──────────┘ └──────────┘

• Hooks (existing) push monitoring events to the dashboard — unchanged
• Channel servers run on each machine alongside Claude Code sessions
• Dashboard → Channel: HTTP POST sends prompts/instructions to a session
• Channel → Dashboard: Claude calls a reply MCP tool, forwarded back via SSE/WebSocket

How it works

1. Channel server (MCP + HTTP listener)

A lightweight MCP server (~60 lines) that:

• Declares claude/channel capability so Claude Code treats it as a channel
• Listens on a local HTTP port for inbound messages from the dashboard
• Emits notifications/claude/channel to push messages into Claude's context
• Exposes a reply tool so Claude can send responses back

Messages arrive in Claude as:

<channel source="command-center" sender="dashboard-user">
Please run the test suite and report results
</channel>

2. Dashboard integration

• New "Send message" input on each session card
• POST to http://<machine>:<port>/message with the prompt
• Receive replies via SSE stream or WebSocket from the channel server
• Display as a chat thread in the session detail view

3. Session startup

Users start sessions with the channel enabled:

claude --dangerously-load-development-channels server:command-center

Or once channels mature, register in .mcp.json:

{
  "mcpServers": {
    "command-center": { "command": "bun", "args": ["./channel-server.ts"] }
  }
}

Why this solves the original problems

Original problem	Channels solution
Session ID mismatch	No tmux launch — sessions self-register via hooks
Duplicate cards	Dashboard doesn't create sessions, only discovers them
Trust dialog	Users start their own sessions
No live terminal needed	Chat-style communication via channel
Single machine only	Channel HTTP endpoints are network-accessible
One-way communication	Full bidirectional via channel notifications + reply tool

Caveats

• Research preview (v2.1.80+) — protocol may change
• Requires claude.ai login (not API keys)
• --channels flag required per session (can't auto-enable from settings yet)
• Teams/Enterprise need admin to enable channelsEnabled: true
• Security: Channel HTTP endpoints exposed on network need auth/allowlisting

Implementation plan

1. Phase 1: Build the channel server (TypeScript/Bun, MCP protocol)
2. Phase 2: Add dashboard UI for sending messages and viewing replies
3. Phase 3: Multi-machine support (channel server registration, network auth)
4. Phase 4: Session launcher that wraps claude --channels (optional, replaces tmux approach)

References

• Channels reference
• Channels guide
• Official channel examples (Telegram, Discord, Fakechat)