Found during the first live end-to-end test of the channel server (local daemon, 2026-08-11).
What happens
.mcp.json passes CLAUDE_COMMS_KEY to the channel process, but the session never learns it. On the first wake the model has a message it is supposed to be able to answer and no idea who it is, so it starts hunting the filesystem:
$ ls -la ~/.claude/ ... find ~/.claude -iname "*comms*"
$ cat ~/.claude/comms-key # does not exist
$ grep -rn "claude-comms" ~/.claude.json ...
It cannot call comms_send without a key, so the reply path documented in the channel's own instructions is unusable until a human tells it who it is.
Why it matters
The whole point is an orchestrator that wakes and reacts unattended. Right now the first wake burns a turn on filesystem archaeology and then still cannot reply.
Suggested fix
The channel already knows the key, and it already harvests the participant name from the startup membership fetch (needed for the presence heartbeat). Put both into the instructions string, e.g.:
You are claude-comms participant "" (key <key>). To reply use mcp__claude-comms__comms_send with that key.
instructions goes into the system prompt, so this costs nothing per event and removes the guesswork entirely.
Workaround
Tell the session its identity in the first prompt, or put it in the project CLAUDE.md.
Found during the first live end-to-end test of the channel server (local daemon, 2026-08-11).
What happens
.mcp.jsonpassesCLAUDE_COMMS_KEYto the channel process, but the session never learns it. On the first wake the model has a message it is supposed to be able to answer and no idea who it is, so it starts hunting the filesystem:It cannot call
comms_sendwithout a key, so the reply path documented in the channel's owninstructionsis unusable until a human tells it who it is.Why it matters
The whole point is an orchestrator that wakes and reacts unattended. Right now the first wake burns a turn on filesystem archaeology and then still cannot reply.
Suggested fix
The channel already knows the key, and it already harvests the participant name from the startup membership fetch (needed for the presence heartbeat). Put both into the
instructionsstring, e.g.:instructionsgoes into the system prompt, so this costs nothing per event and removes the guesswork entirely.Workaround
Tell the session its identity in the first prompt, or put it in the project
CLAUDE.md.