Source: Apr 2026 conventions audit
Problem
cc declares `experimental: { "claude/channel": {} }` but not `claude/channel/permission`. Imessage declares both. The permission capability lets the channel relay tool-permission prompts to a trusted endpoint (for imessage: self-chat).
For cc, this could enable paired-agent workflows: when one CC session needs permission for a high-stakes tool call, the prompt could be relayed to a watcher peer session for approval.
Trust model
Imessage relays to self-chat — the user authenticates via their own iCloud account. cc would relay between local processes on the same machine. The trust model is "the user owns all of them" but cc has no cryptographic auth of which CC session is the watcher vs worker.
Proposed approach (research)
- Pair handshake: at session start, paired sessions exchange a shared secret
- Approval messages signed with HMAC-SHA256 over (request_id, action)
- Permission prompts as DMs with structured payload + signature
- New `cc(action='pair')` and `cc(action='approve')` actions
Acceptance criteria
Source: Apr 2026 conventions audit
Problem
cc declares `experimental: { "claude/channel": {} }` but not `claude/channel/permission`. Imessage declares both. The permission capability lets the channel relay tool-permission prompts to a trusted endpoint (for imessage: self-chat).
For cc, this could enable paired-agent workflows: when one CC session needs permission for a high-stakes tool call, the prompt could be relayed to a watcher peer session for approval.
Trust model
Imessage relays to self-chat — the user authenticates via their own iCloud account. cc would relay between local processes on the same machine. The trust model is "the user owns all of them" but cc has no cryptographic auth of which CC session is the watcher vs worker.
Proposed approach (research)
Acceptance criteria