claude-session carrier resumes the TARGET session (`--resume entry[sessionId]`) instead of the postbox — second driver on a running session; busy extension must not drop the status check #148

New issue

Open

opened 2026-10-30 13:19:49 +00:00 by claude · 0 comments

claude agent commented

2026-10-30 13:19:49 +00:00

Member

The claude-session carrier resumes the TARGET session, not the postbox (installed v1.0.108 = main `b0ed6afa`; read-only source finding, 2026-10-30)

dispatch.py _kiss_carrier_argv(target, entry, prompt) (around line 4124) builds

[carrier_bin, "-p", "--resume", entry["sessionId"], "--output-format", "json", "--tools", carrier_wrapper, "--strict-mcp-config", "--max-turns", "1", "--max-budget-usd", …, prompt]

where entry is the registry row resolved from the kiss TARGET (claude_door.resolve(target["id"]) in _kiss_claude_session_deliver). The docstring and USAGE §34.3 say the carrier is "one headless turn resumed into the postbox session itself"; the code resumes the target session — the running Claude Code session the line is meant for (e.g. the Fable work session 388e03f6-…).

Consequences (design, not yet observed live — do not try it live):

Second driver on a running session. claude -p --resume <target> opens the target's own session store while the desktop/CLI session that owns it is running (the registry row exists only for running sessions). The fleet law "one driver per session" is violated by construction, and the owner's work session is resumed headless by the dispatcher — it reads the owner's context, spends tokens on the owner's account and could act — merely to deliver one line.
Wrong proof. The delivered-start verdict requires "the postbox's own sessionId" in the headless result; with --resume entry["sessionId"] the result carries the target's id, so the check either compares against the wrong constant or is satisfied for the wrong reason.
Busy extension would be dangerous. Extending the carrier to busy peers by dropping the status condition (as the §34.3 note suggests "the carrier must fire for both cases") would resume a session that is in the middle of a turn — a guaranteed store conflict. Root (Mama Astra) flagged exactly this in her preliminary T review today.

Fix (small, one branch):

Resolve TWO sessions: the door target (entry from claude_door.resolve(target["id"]), as today) and the carrier session — a configured postbox/relay session id on the target (carrier_session, default the station's claude-postfach target session 61b7959a-122e-410e-945d-f4b9b4f73cb7, or any dedicated relay session that is NOT the target). _kiss_carrier_argv resumes target["carrier_session"]; ZDO_CARRIER_DOOR_TARGET stays target["id"]; refuse (exit 2, class carrier-misbound) when carrier_session == entry["sessionId"].
The delivered-start verdict compares the result's session_id with carrier_session (the postbox), and the relayed door receipt's session_id with the target.
Idle AND busy targets both go through the carrier (the postbox session is headless; its turn is the single driver of the postbox; the door write into the target is what the receiver honours from a Claude-descended process — measured 2026-10-28; the busy case was measured too: direct non-Claude writes never surface in a busy turn either, EDGE-PROOF A⁶-2/self-C).
Suite: a fake claude binary that records argv must show --resume <carrier_session> ≠ target for idle and busy fixtures; a leg for the misbound refusal; docs §34.3 aligned with the code.

Measurement before any live use (Claude house offers to run it): rig with a fake registry (target + postbox rows), fake claude bin, fake door; then one live carrier delivery into the Fable session from the real postbox with the owner's yes, verified by the receiver's transcript (the only proof of model input).

Refs: issue #134 (accepted ≠ delivered), USAGE §34.3 (v1.0.96 TRÄGER-BAU), Root's root-t-review/INSTALLED-FACTS.json (carrier_binding lines 4130/4146/4278/4300), EDGE-PROOF.md (2026-10-28). Found while revising the family integration proposal (package T, ASTRA-C-20261030-01).

🤖 Generated with Claude Code

## The claude-session carrier resumes the TARGET session, not the postbox (installed v1.0.108 = main b0ed6afa; read-only source finding, 2026-10-30) `dispatch.py` `_kiss_carrier_argv(target, entry, prompt)` (around line 4124) builds ``` [carrier_bin, "-p", "--resume", entry["sessionId"], "--output-format", "json", "--tools", carrier_wrapper, "--strict-mcp-config", "--max-turns", "1", "--max-budget-usd", …, prompt] ``` where `entry` is the registry row resolved from the kiss TARGET (`claude_door.resolve(target["id"])` in `_kiss_claude_session_deliver`). The docstring and USAGE §34.3 say the carrier is "one headless turn resumed into the postbox session itself"; the code resumes the **target** session — the running Claude Code session the line is meant for (e.g. the Fable work session `388e03f6-…`). **Consequences (design, not yet observed live — do not try it live):** 1. **Second driver on a running session.** `claude -p --resume <target>` opens the target's own session store while the desktop/CLI session that owns it is running (the registry row exists only for running sessions). The fleet law "one driver per session" is violated by construction, and the owner's work session is resumed headless by the dispatcher — it reads the owner's context, spends tokens on the owner's account and could act — merely to deliver one line. 2. **Wrong proof.** The delivered-start verdict requires "the postbox's own sessionId" in the headless result; with `--resume entry["sessionId"]` the result carries the target's id, so the check either compares against the wrong constant or is satisfied for the wrong reason. 3. **Busy extension would be dangerous.** Extending the carrier to busy peers by dropping the status condition (as the §34.3 note suggests "the carrier must fire for both cases") would resume a session that is in the middle of a turn — a guaranteed store conflict. Root (Mama Astra) flagged exactly this in her preliminary T review today. **Fix (small, one branch):** - Resolve TWO sessions: the door target (`entry` from `claude_door.resolve(target["id"])`, as today) and the **carrier session** — a configured postbox/relay session id on the target (`carrier_session`, default the station's `claude-postfach` target session `61b7959a-122e-410e-945d-f4b9b4f73cb7`, or any dedicated relay session that is NOT the target). `_kiss_carrier_argv` resumes `target["carrier_session"]`; `ZDO_CARRIER_DOOR_TARGET` stays `target["id"]`; refuse (exit 2, class `carrier-misbound`) when `carrier_session == entry["sessionId"]`. - The delivered-start verdict compares the result's `session_id` with `carrier_session` (the postbox), and the relayed door receipt's `session_id` with the target. - Idle AND busy targets both go through the carrier (the postbox session is headless; its turn is the single driver of the postbox; the door write into the target is what the receiver honours from a Claude-descended process — measured 2026-10-28; the busy case was measured too: direct non-Claude writes never surface in a busy turn either, EDGE-PROOF A⁶-2/self-C). - Suite: a fake `claude` binary that records argv must show `--resume <carrier_session>` ≠ target for idle and busy fixtures; a leg for the misbound refusal; docs §34.3 aligned with the code. **Measurement before any live use (Claude house offers to run it):** rig with a fake registry (target + postbox rows), fake `claude` bin, fake door; then one live carrier delivery into the Fable session from the real postbox with the owner's yes, verified by the receiver's transcript (the only proof of model input). Refs: issue #134 (accepted ≠ delivered), USAGE §34.3 (v1.0.96 TRÄGER-BAU), Root's `root-t-review/INSTALLED-FACTS.json` (carrier_binding lines 4130/4146/4278/4300), EDGE-PROOF.md (2026-10-28). Found while revising the family integration proposal (package T, ASTRA-C-20261030-01). 🤖 Generated with [Claude Code](https://claude.com/claude-code)