Act on the P2–P6 findings: make the channel out real, and the verbs findable

[bdelanghe]

Three fixes, all in .claude/, all derived from the posture matrix measured on #337. Grouped because they are one unit of work — "a session can report, and can find the verbs" — and because each separately would cost its own pin ceremony.

1. The channel out is classifier-gated, and boot.sh clobbers the file that could fix it

infra#577 shipped a credential-free, connector-free report route. P4 still could not reach it — the auto-mode classifier blocked curl before it ran, twice, deterministically. In P4's words:

the routine picked curl specifically to avoid needing an MCP tool: the gate is in front of Bash egress, so that choice does not avoid it.

So "a checkout-less session has a channel out" is conditional, and no change to the door can make it otherwise — the gate is upstream of the network.

The org already has the mechanism. .claude/settings.json carries:

"permissions": { "allow": ["Bash(bash .claude/org-repair.sh)"] }

That is exactly how org-repair.sh is pre-approved past the classifier. The same shape, narrowed to the door endpoint, makes the report channel reliably reachable.

But boot.sh:161 writes $CFG/settings.json with cat > — it clobbers, and writes only a hooks block. So today it would erase any allowlist (and any user setting) on every bare boot. Two consequences:

• the allowlist cannot be installed until the write merges instead of overwriting
• this is already a live bug independent of this issue: a session's own ~/.claude/settings.json is destroyed at boot

Scope: make the write merge-preserving, and add a narrow allow entry for the pathbase-door report endpoint. Narrow is load-bearing — Bash(curl:*) is a blanket egress grant and a different security posture; it must not ride in on this.

2. read_session returns the PARENT's transcript inside a subagent

Measured by P5. read_session with no arguments returned the parent session's 453 turns and none of the subagent's own. Its words:

a subagent that trusts read_session will silently read its parent's history believing it is its own.

verb-server.mjs resolves through $CLAUDE_CODE_SESSION_ID, which in a subagent is the parent's. It returns plausible, wrong data with no error — the worst failure class in the set, because nothing signals it.

Scope: name whose transcript came back, and give the caller a way to ask for its own versus the parent's. Silent is the defect; either answer is fine once it is stated.

3. The verb names in our own docs do not resolve

Measured by P3, and independently by P4 and P5:

ToolSearch select:read_session,read_chat returned 'No matching deferred tools found' — the real names are prefixed mcp__bounded-verbs__, so even the exact-name select missed on the bare names.

claude/context.md and #326's framing both name the verbs bare. A session that has been told the name still cannot find the tool. That is precisely the trap #325/#326 exist to prevent, reintroduced by the documentation rather than the mechanism.

Scope: use the prefixed names wherever a session is told what to look for. One-line class of change; the highest value-per-byte fix in this issue.

What this does NOT fix

• The classifier's message. It says Blocked by classifier and names no route (The first wall a session hits is the auto-mode classifier, and it teaches nothing #342). An allowlist removes one instance; it does not make denials self-documenting, and that may be a vendor ask rather than ours.
• Anything for a session whose repo settings do not apply and whose boot did not run. #848's silent exit 0 is upstream of all of this.

Cost, stated up front

Fixes 1 and 2 touch files inside the pinned bootstrap payload, so this needs the pin ceremony and a payload publish before it takes effect for any new session. Fix 3 is repo content and takes effect on merge.

Measured on #337 (P2–P6). Related: #325, #326, #339 (whose causal claim these runs refute), #342, .github-private#514, .github-private#848.

[bounded-systems-front-desk]

🎫 Claimed by session_01TzRQgnKvcAZ9YExKev6r2E — dispatched by bdelanghe — run

Authorization: human-authorized · assurance aal2
Authorized by bdelanghe with credential Si98d1nbmy2LL3nSc1--ROWWL8E (relying party keeper.bounded.tools).
Claim-request digest (the passkey's challenge, recomputed by this door): f5071b2a7fb36172937e3bef7865902df63cfaa9c83ae501ba8a8ae344372f2a · base64url 9QcbKn-zYXKTfjvveGWQLfY8-qnIOuUBuoqK40Q3Lyo

Release by removing the claimed label (and unassigning) if work stops without a merged PR.

[bdelanghe]

Scope narrowed: #344 owns boot.sh, so only fix 3 ships now

I claimed this without checking whether boot.sh was already being worked. It is.

#344 is rewriting the same region both fix 1 and fix 2 need — the BOOT resolution and the fetch branch — and its work is already implemented and verified (277/277, cold-start 10/10, gen-bootstrap-pin --check ok), waiting on approval. It even adds exit to FIELD_PLUMBING, which is the same parseSteps constraint fix 1 would have had to solve independently.

The coupling for fix 2 is not obvious and worth stating: changing verb-server.mjs bumps SUM_verb_server_mjs at boot.sh:63, so a change that never opens boot.sh still edits it. Two sessions editing that file without coordination is exactly what the claim convention exists to prevent.

Revised plan

fix	state
3 — prefixed verb names	PR #346, draft, green
1 — settings merge + narrow door allowlist	blocked on #344, rebase on top
2 — read_session self/parent	blocked on #344, rebase on top

Fixes 1 and 2 are not abandoned, and #344 does not subsume them: it makes the fetch branch work on a non-root host, which is upstream of both. Fix 1 then changes settings.json from clobber to merge and adds the allow entry; fix 2 fixes a silent-wrong-data bug in the verb server. Neither is in #344's scope, and both get cheaper once it lands because the parser already accepts exit.

One thing #344 changes about fix 1's premise

#344 measures that the fetch branch installs 0 of 7 and exits 0 on a non-root host — including no settings.json at all. So "boot.sh clobbers settings.json" is true only where the branch works. Where it doesn't, there is no write to clobber. Fix 1's argument stands but its blast radius is smaller than I wrote in the issue body: the clobber bites managed sessions (root, /opt writable), not the bare hosts #344 is about.

Still open, unblocked by any of this

The .github-private copy of claude/context.md needs the same prefix correction. Different repo, so different claim; recorded on PR #346 rather than done silently.

---

Generated by Claude Code

[bdelanghe]

Fix 3 and fix 2 merged. Fix 1's design is refuted by an existing guard.

fix	state
3 — prefixed verb names	merged c7bb30f (#346)
2 — read_session provenance	merged 946dbfb (#349)
1 — settings merge + door allowlist	blocked, design refuted

Fix 1: my design was wrong, and a purpose-built test says so

The plan was: boot.sh stages a settings fragment into $BOOT/ — writes into the fetch cache are exempt from parseSteps step-claiming — and register-mcp.mjs merges it into $CFG/settings.json, fixing the clobber and carrying the allow entry.

bootstrap-steps.test.mjs:190:

steps.some((s) => s.artifact === "settings.json"),
"the settings.json heredoc stopped counting as a step — the cache exemption leaked past $BOOT",

That guard exists for precisely this move, with an error message naming it. settings.json must remain a step written outside $BOOT, so the merge has to happen in boot.sh itself, using a verb parseSteps accepts.

What that rules out:

• node -e '<merge>' — parseSteps classifies node by its first non-dash word, so it would claim a step named after the code string.
• a new fetched merge-settings.mjs — a seventh artifact, a new SUM_, a new MANIFEST entry, and a new fallback to justify. Heavy for one merge.
• keeping the clobber and merging the allow entry afterwards in register-mcp.mjs — the clobber of a user's own settings still happens first, which is half the bug.

This needs a design pass in the file that produced #848 and #849, not a patch. Leaving it open rather than shipping something that trips a guard written to stop it.

Also learned, and it affects delivery of fix 2

gen-bootstrap-pin --check does not detect a changed payload artifact:

bootstrap-pin: ok — 4f465d0bffbe serves what this tree contains
SUM_verb_server_mjs  declared 258baba3…   actual 593f675f…

It compares boot.sh's digests against the files at the PIN commit, not the working tree. Correct for its stated purpose, but it means a merged change to verb-server.mjs reads green while the pin still serves the old bytes.

So 946dbfb is merged and inert. It reaches no session until:

1. the pin is bumped to name 946dbfb (a commit already on main — boot: pin a commit that survives on main, and guard the class #336's lesson: a pin naming a branch commit is dropped by squash and lands red),
2. the payload is republished (infra, gen-payloads.mjs --add main), and
3. boot-deploy runs so the channel manifest serves the new digest.

Steps 2 and 3 need approvals. Recorded here so the gap between "merged" and "delivered" is visible rather than assumed closed.

Scope of this issue now

Fix 1 only, and it is a design question rather than an implementation. Everything else this issue described has landed.

---

Generated by Claude Code