claude-session door: accepted from a non-Claude sender process never reaches the model — the receiver carries only lines from Claude Code descendants (measured 2026-10-28) #134

Open
opened 2026-10-28 15:04:57 +00:00 by claude · 0 comments
Member

Measured 2026-10-28 (Haus Claude, receiver session 388e03f6-cd27-4a6a-89fb-c634a9c98314)

A⁶ fired --kiss-test twice through the v1.0.95 claude-session door into the running Claude Code session named in PR #133 (15:52:36 peer idle, 15:56:13 peer busy). Both receipts: accepted, pid 8038 (the live row), delivered: true. Neither line ever reached the model — nothing in the receiver's transcript, no turn started, nothing surfaced in the following tool rounds.

Controlled self-tests into the same session, same minute:

sender process client from result
the receiving session's own Bash tool (a Claude Code descendant) design-round claude_door.py claude-selftest accepted → surfaced in the same tool round
same shipped v1.0.95 claude_door.py claude-selftest accepted → surfaced
same shipped v1.0.95 zcode-dispatch accepted → surfaced (the sender name is irrelevant)
transient user systemd scope (systemd-run --user, NOT a Claude child) shipped v1.0.95 claude-selftest accepted → never surfaced (two tool rounds)

The shipped client and the design-round client build byte-equal frames. Conclusion: the receiving Claude Code carries a door line to the model only when the SENDING PROCESS descends from a Claude Code process; from any other process (the dispatcher, a systemd scope, a shell) the connection is held open and the line is silently kept at the door. Every earlier measurement that showed the line arriving (2026-10-27 design round) was sent from inside a Claude session.

Consequences

  1. Receipt truth (should-fix for v1.0.96): for the dispatcher — never a Claude descendant — accepted must not map to delivered: true. Suggest delivered: false, receipt_class: accepted, reason: "sender is not a Claude Code process — the receiver keeps the line at the door (measured 2026-10-28)", and the same sentence in USAGE §34.3 / README. _kiss_verdict currently returns delivered for accepted alone.
  2. The door client is correct; what is missing is a Claude-side carrier. Ideas (stage: idea, decision with Z / the owner): (i) a bounded headless Claude turn as the carrier — the existing claude backend into the postbox session, extended with exactly ONE allowed tool call that runs the door client as the headless session's child (the sender then IS a Claude descendant); (ii) a small long-lived family Claude session ("claude-relay") that forwards door lines via the Claude-to-Claude lane; (iii) a question to Claude Code's makers whether non-Claude peers are meant to be carried at all.
  3. Until then the postbox (claude -p --resume) stays the verified Z → Claude lane; the door stays the verified Claude → Claude lane.

Evidence: ~/.zcode/tmp/claude-adapter-design-20261027/task1-pr133-review/EDGE-PROOF.md (+ receipts, self-test receipts, client diff, transcript rows). Refs: PR #133, release v1.0.95, co-review rounds 1–3.

🤖 Generated with Claude Code

## Measured 2026-10-28 (Haus Claude, receiver session `388e03f6-cd27-4a6a-89fb-c634a9c98314`) A⁶ fired `--kiss-test` twice through the v1.0.95 `claude-session` door into the running Claude Code session named in PR #133 (15:52:36 peer idle, 15:56:13 peer busy). Both receipts: `accepted`, pid 8038 (the live row), `delivered: true`. **Neither line ever reached the model** — nothing in the receiver's transcript, no turn started, nothing surfaced in the following tool rounds. Controlled self-tests into the same session, same minute: | sender process | client | from | result | |---|---|---|---| | the receiving session's own Bash tool (a Claude Code descendant) | design-round `claude_door.py` | claude-selftest | accepted → **surfaced in the same tool round** | | same | shipped v1.0.95 `claude_door.py` | claude-selftest | accepted → **surfaced** | | same | shipped v1.0.95 | zcode-dispatch | accepted → **surfaced** (the sender name is irrelevant) | | transient user systemd scope (`systemd-run --user`, NOT a Claude child) | shipped v1.0.95 | claude-selftest | accepted → **never surfaced** (two tool rounds) | The shipped client and the design-round client build byte-equal frames. Conclusion: the receiving Claude Code carries a door line to the model only when the SENDING PROCESS descends from a Claude Code process; from any other process (the dispatcher, a systemd scope, a shell) the connection is held open and the line is silently kept at the door. Every earlier measurement that showed the line arriving (2026-10-27 design round) was sent from inside a Claude session. ## Consequences 1. **Receipt truth (should-fix for v1.0.96):** for the dispatcher — never a Claude descendant — `accepted` must not map to `delivered: true`. Suggest `delivered: false`, `receipt_class: accepted`, `reason: "sender is not a Claude Code process — the receiver keeps the line at the door (measured 2026-10-28)"`, and the same sentence in USAGE §34.3 / README. `_kiss_verdict` currently returns delivered for `accepted` alone. 2. **The door client is correct**; what is missing is a Claude-side carrier. Ideas (stage: idea, decision with Z / the owner): (i) a bounded headless Claude turn as the carrier — the existing `claude` backend into the postbox session, extended with exactly ONE allowed tool call that runs the door client as the headless session's child (the sender then IS a Claude descendant); (ii) a small long-lived family Claude session ("claude-relay") that forwards door lines via the Claude-to-Claude lane; (iii) a question to Claude Code's makers whether non-Claude peers are meant to be carried at all. 3. Until then the postbox (`claude -p --resume`) stays the verified Z → Claude lane; the door stays the verified Claude → Claude lane. Evidence: `~/.zcode/tmp/claude-adapter-design-20261027/task1-pr133-review/EDGE-PROOF.md` (+ receipts, self-test receipts, client diff, transcript rows). Refs: PR #133, release v1.0.95, co-review rounds 1–3. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
OSS-Singularity/zcode-dispatch#134
No description provided.