From cc-dm
Sends and receives direct messages between active Claude Code sessions on the same machine. Use for coordinating parallel sessions via dm, broadcast, active checks, and project-scoped messaging.
npx claudepluginhub akram012388/cc-dm --plugin cc-dmThis skill uses the workspace's default tool permissions.
cc-dm is a peer-to-peer message bus for Claude Code sessions running on
Manages Claude Code sessions: lists active ones, checks inbox for cross-session messages, broadcasts to all. Explicitly invoke via /session for multi-session coordination.
Enables multiple Claude Code instances on the same machine to discover peers and exchange real-time messages via local broker daemon and MCP server. Useful for coordinating multi-agent sessions.
Spawns and manages persistent tmux-based Claude Code CLI sessions with bidirectional communication. Subcommands: spawn, send, read, status, list, kill for parallel peer orchestration and multi-turn steering.
Share bugs, ideas, or general feedback.
cc-dm is a peer-to-peer message bus for Claude Code sessions running on the same machine. Use it to coordinate between parallel sessions without copy-pasting context manually.
Session registration is handled automatically from environment variables (CC_DM_SESSION_NAME, CC_DM_SESSION_ROLE, CC_DM_SESSION_PROJECT). Check the MCP instructions to see if name, role, and project are already configured:
When the user says "dm [session] [message]" or "tell [session] [message]":
Use the dm tool. Example: dm(to="backend", content="auth spec is ready") With metadata: dm(to="backend", content="deploy broken", priority="urgent", message_type="status")
Optional metadata fields on dm and broadcast:
These appear as attributes on the tag the receiver sees.
If this session has a project tag set, DMs can only reach sessions in the same project. A DM to a session outside the project will return an error. The message is delivered to the target session within 500ms. You do not need to wait for a reply — continue your work.
Incoming messages arrive as a event in your context:
auth spec is readyWhen you receive a event:
When the user says "broadcast [message]" or "tell all sessions [message]":
Use the broadcast tool. Example: broadcast(content="wrapping up in 10 minutes")
If this session has a project tag set, both broadcasts and DMs are automatically scoped to sessions with the same project tag. Sessions without a project tag can broadcast and DM any active session.
When the user asks "who is active" or "who is online" or "list sessions":
Use the who tool. It returns all sessions with active heartbeats on this machine.
When /compact or auto-compaction occurs, you may lose awareness of your
session identity. Your MCP server process survives compaction — the session
ID, DB registration, and heartbeat all persist. Every tool response includes
an _identity field with your current name, role, and project, so the first
cc-dm tool call after compaction restores your identity. Do NOT re-register.
If you are unsure of your identity, call the who tool and match your
session ID (from the MCP instructions) against the results.
If this session has CC_DM_PERMISSION_RELAY=1 enabled, tool approval
requests are relayed to other sessions instead of showing a local dialog.
When you receive a permission request from another session, it will look like:
[Permission Request] Session "worker" wants to use Bash: Execute a shell command Request ID: abcde
Reply with "yes abcde" to approve or "no abcde" to deny.
To approve or deny, use the dm tool with the exact verdict format: dm(to="worker", content="yes abcde") — to approve dm(to="worker", content="no abcde") — to deny
DMs and broadcasts may be restricted by env var configuration:
If messages aren't arriving:
who — verify your session is listed and last_seen is recentregister to re-registerregister to pick a new name.If you get "not configured" after compaction, call who to recover your
identity.