read_code_session: a Claude Code session URL should read like a share link

[bdelanghe]

https://claude.ai/code/session_015MHtz7BxTVDRuvvG5o7rGi should be as readable as a claude.ai/share/… link is today via read_chat. It is not, and #337's dogfood is the proof: a child session completed its work and the session that launched it could not retrieve a single sentence of the result.

read_chat reads shared chats. read_session reads local ones off ~/.claude/projects. A Code session in another container is neither, and that is the whole missing leg.

Measured, 2026-09-01

Every direct read path, from a session with the full claude-code-remote MCP surface attached:

path	result
WebFetch https://claude.ai/code/session_015MHtz7BxTVDRuvvG5o7rGi	403 (only claude.ai/code/artifact/{uuid} is fetchable)
WebFetch claude.ai/api/claude_code/sessions/{id}	403
WebFetch claude.ai/api/sessions/{id}/events	403
WebFetch claude.ai/api/claude_code/session/{id}/events	403
get_session({session_id})	record only — title, status, timestamps, usage, post_turn_summary. No turns.
ToolSearch select:…__list_events	No matching deferred tools found
ToolSearch select:…__send_message	No matching deferred tools found
ListAgents	No reachable agents — a cloud session is a different container
ListMcpResourcesTool	GitHub UI resources only; no transcript resource
read_session({session_id})	resolves against local disk; another container's disk is not on it

Note the shape of get_session's own reply envelope: it is labelled "Another Claude session's record, transcript events, or run log (JSON)". The envelope for transcript-bearing reads already exists on this surface. Nothing on this surface fills it.

And create_session's own tool description says: "Combine with send_message for fan-out orchestration: spawn a sibling, send it a task, poll list_events for the result." Both named tools are absent. The documented orchestration loop cannot be closed.

The gap is directional

We can push into another live session — create_trigger with persistent_session_id delivers a prompt and wakes it. We cannot pull. Push-only plus a bare session with no out-channel (#337, measurement 6) means work happens and the result is stranded in a transcript nobody can open.

Two candidate doors

(a) Surface the platform read — preferred. list_events (or any transcript read) on the claude-code-remote MCP, authenticated as the account that already owns the session. No new credential, no new tier, nothing held anywhere. read_code_session on bounded-verbs then becomes what read_session already is: a thin, paginating adapter over an audited underlying reader, same transcript/graph modes, same limit/offset contract, feeding the same toolpath Graph. This is a vendor-surface ask, not something we can build — so the honest first step is a probe and a request, not an implementation.

(b) A relay tier holding a credential. The chat-fetch.sh → claude-relay shape, extended to Code session URLs. This puts a long-lived credential behind a door and reads a surface the vendor has not published — the same ToS-gray class we deliberately deferred for private un-shared chats in .github-private#835 Phase 2. It should stay deferred for exactly the same reason, and it should be deferred by the same decision, not drifted into because (a) was slow.

Recommendation

Do (a): probe for the tool, ask for it, and record the refusal or the grant. Do not do (b) as a workaround.

In the meantime the buildable half is the other direction — give a spawned session a channel out so a push-only world still returns answers (#337's fix 2). That needs no vendor surface at all.

Scope of this issue

• Probe whether list_events / an equivalent transcript read exists on any surface reachable from a session, and record the result either way
• If it exists: read_code_session verb on bounded-verbs, matching read_session's pagination and modes, plus a test pinning its refusal sentence
• If it does not: record the refusal in docs/handoffs/chat-relay.md next to the measured 403 table above, so the next session does not re-derive it
• Either way: claude/context.md gains a bullet for Code session URLs, so a session reaches for the verb instead of inventing a fetch — the Org verb MCP server: expose read_chat (the relay) as a session tool via .mcp.json + register-mcp.mjs #326 lesson (a blind agent invented a bot-gate bypass across six dead ends rather than find the tool that existed)

Sibling of #337. Related: #325, #326 (discoverability), .github-private#835 (private-chat Phase 2, and the ToS line this issue must not cross).

[bdelanghe]

Door (c): the session publishes its own Graph through the pathbase door

The two doors above both frame this as a pull — get a transcript out of a container we don't control. There is a third framing that inverts it, and it is the one that fits what is already built.

toolpath/pathbase is the addressing and read layer, not the extraction layer:

• path p derive claude turns session JSONL into a Graph
• the pathbase door (pathbase.bounded.tools, DOOR_HOST in claude-relay.ts) stores it under a live claim
• path p incept claude lands a Graph back into ~/.claude/projects as a real, resumable session

For shared chats that round trip already exists and is deployed — chat-fetch.sh <url> --incept walks the whole path today. For Code sessions only the first hop is missing: getting the Graph out of the container.

So instead of pulling, the session publishes itself on the way out. Reading claude.ai/code/session_X becomes reading a pathbase id.

Why this is better than (a) or (b)

• No vendor surface. Does not depend on Anthropic exposing list_events, which (a) can only ask for and not build.
• Attributable. Published under a claim, like every other effect in the org — not a credential sitting in a relay tier.
• Clears the .github-private#835 line without crossing it. These are the session's own bytes going out its own door. No third-party surface is read, so none of Phase 2's ToS-gray reasoning applies.

Honest limits

• Opt-in and forward-only. A session that already ran without the bootstrap stays unrecoverable — session_015MHtz7BxTVDRuvvG5o7rGi (Dogfood: does a checkout-less session actually get the verbs? #337 v1) is the standing example. Doors (a)/(b) could reach backwards; (c) cannot.
• Needs the same out-channel that is already the blocker. Dogfood: does a checkout-less session actually get the verbs? #337 v2's needs_action names it exactly: no GitHub tool, no relay bearer, no push. (c) does not route around Dogfood: does a checkout-less session actually get the verbs? #337's fix 2 — it is fix 2 plus a destination.
• Publishing is not reading. This copies transcript bytes into a store. Retention and consent are a design question in their own right: a session that publishes itself by default is a materially different posture from one that publishes on request, and that choice should be made deliberately rather than inherited from whichever is easier to implement.
• Does not cover sessions we do not run. Someone else's un-bootstrapped session is still opaque.

Effect on scope

(c) does not replace (a) — a backwards read of an already-finished session is a capability only (a) can give, and the probe is still worth doing and recording. But (c) is the one we can build, and it should be sequenced first because the org already owns every piece of it except the bearer.

Revised recommendation: (c) for new sessions, (a) probed and requested for old ones, (b) still deferred.

---

Generated by Claude Code

[bdelanghe]

Sequenced plan for the remaining session-read work

Produced by a 14-agent design pass (4 survey → 4 design → 5 adversarial verify → 1 synthesis), read-only, no claim taken. Three of its findings correct things asserted earlier on this issue and on #337 — read those first.

Corrections to the record

1. The 403 table in this issue's body is indeterminate, not measured. Every probe was run through the session's agent proxy, which is itself documented to return 403/405/407, and no control fetch was taken. The org's own control rule (a 403 can be the client's flavor, not the route's policy) makes these unestablished. api.claude.ai is additionally wrong: it was never reached — NXDOMAIN from two vantages, Add a self-test caller for repo-standard.yml so caller-breaking revisions fail in CI #56 — not 403. A measured positive was also dropped from the table: claude.ai/code/artifact/{uuid} is fetchable. Step 13 re-runs these from the live relay vantage.
2. boot.sh does not ship the verbs to a bare session. Dogfood: does a checkout-less session actually get the verbs? #337's comment says it ships verb-server.mjs + .mcp.json into /opt/bounded-boot. Its checkout-less branch installs 0 of 6 components and exits 0 on any non-root host (.github-private#848). Nothing in the boot payload can be assumed present in a bare container.
3. The channel out does not need a bearer. The pathbase door already accepts an anonymous, credential-free upload gated on a live Front Desk claim, and posts its own testimony comment on the claim issue. What it does not do is carry any caller text — so today it delivers provenance, not a report. That is a much smaller gap than "a session needs a credential".

Consequence: the broker /lease relay-bearer tenant is dropped, on two independent fatal verdicts. Details in "Dropped, explicitly" below.

---

1. Where this actually stands

The read path works in one direction only. A claude.ai share link is readable end to end today (chat-fetch.sh → bounded.tools relay → toolpath Graph → pathbase door, deployed, --incept lands a real session); a claude.ai/code/session_<id> is not, and every probe of that surface so far was run through an agent proxy that itself returns 403, with no control fetch, so those negatives are indeterminate, not measured. We can push into a live session (create_trigger + persistent_session_id) and never pull. The write path is better than the dogfood claimed: the pathbase door takes an anonymous, credential-free upload gated on a live Front Desk claim and posts its own testimony comment on the claim issue — but that comment carries no findings, the graph is private with no read route, and on a public repo no URL is posted at all, so today's "channel out" delivers provenance, not a report. boot.sh's checkout-less branch installs 0 of 6 components and exits 0 on any non-root host (#848), so nothing shipped through the boot payload can be assumed present in a bare session. Nothing in this workstream is in flight as a PR, and nothing carries a claim.

2. The plan

Every step below requires a Front Desk claim backed by a passkey approval. None has been taken.

1. Set the claim and trailer mechanics before any code. One claimed issue per repo touched (.github, .github-private, infra, bounded.tools); PRs that must not close their issue carry Claim-issue: owner/repo#N, and the squash-merge caveat (#781) applies. Open a sibling issue for the out-channel work — #337 is the measurement issue and must stay OPEN, because a closed issue 403s at the door (evaluateClaim: "issue is not open"). Who: session-with-claim. Blocked on: a claim.

2. Measure .github-private#514's untested repair: create_session with source_url. One spawn. If a child gets the checkout, it gets path, verb-server, the org context and the claim convention, and most of #337's premise changes. Record on #514 either way. Who: session-with-claim. Blocked on: step 1.

3. In the same spawn, measure three bare-container facts nobody has established: (a) does path finish its ~5-minute compile inside a short child's life, (b) is pathbase.bounded.tools reachable from that egress, (c) does an anon POST with no claim return 403 (not 000/404). #545's only session-side measurement of this surface was 404 on every route. Everything in steps 6–9 is asserted, not measured, until this runs. Who: session-with-claim. Blocked on: step 2.

4. Fix .github-private#848 and #849 in one PR — the checkout-less branch failing silently with exit 0, and the anchor/payload shared-origin provenance gap. Same file, same pin ceremony. Until this lands, "a bare session has the verbs" is unfalsifiable. Repo/file: bounded-systems/.github → .claude/boot.sh, gen-bootstrap-pin.mjs. Who: session-with-claim + owner-device for the pin ceremony. Blocked on: .github-private#847, or an accepted Face ID for this one bump.

5. Fix .github-private#839 item 1 — the public claude/context.md is missing the chat-relay paragraph, so bare sessions are being told the relay does not exist. The blocker is the auto-mode permission classifier (#850 item 6), not policy. Repo: .github. Who: owner-device (or a surface the classifier does not refuse). Blocked on: nothing technical.

6. Owner rulings, before any door code (details in §4): the narrowed #525 disclosure question, whether the door may carry caller-authored text, and whether transcript upload is gated on a redaction gate. Who: owner-device. Blocked on: nothing.

7. Give the door a findings-carrying route. Today postBack composes its comment from claimant/visibility/repo only and never includes a caller note, and checkDocument 422s any second top-level key — so a note cannot ride the upload. Add either a short caller-supplied note (query param, hard length cap, plain-text escaped, included in postBack's body) or an upload-free report route: claim verified, comment posted, nothing sent to the vendor. Recommended: the upload-free route first — it is the whole channel out and it sidesteps disclosure, redaction, retention and deletion entirely. This is a real capability expansion (anyone who can name a live claim can post arbitrary text as the front-desk App) and needs its own security review plus the existing 6/hour, 40/lifetime ceilings. Repo/file: infra/cloudflare/pathbase-door/src/index.mjs, SECURITY.md. Who: session-with-claim. Blocked on: step 6.

8. Add the report_out verb beside read_chat/read_session: {repo, issue, text}, repo/issue validated against parseDoorPath's grammar pre-network, door host a literal, owner never a parameter, door refusals (403 / 413 / 422 / 429-hourly vs 429-lifetime / 5xx) surfaced verbatim, and "path installing" distinguished from "path absent". State in the tool description that this is the server's first write verb — callers who allowlisted bounded-verbs as read-only are now granting an issue comment. Repo/file: .github/.claude/verb-server.mjs + tests. Who: session-with-claim. Blocked on: step 7.

9. Make the channel discoverable in the healthy case. The dispatcher injects context only for manifest entries that FAIL, so an entry that reports ok:true when the channel works tells a working session nothing — which is the exact defect being fixed. Either make the entry always contribute, or put the instruction in the verb's own description. The block must name only paths a bare session can walk: the claim comes from the spawner as repo+issue in the prompt. It must not say "dispatch claim-ticket.yml" or "run claim-ceremony.mjs" — neither the GitHub tool nor that script exists in a bare container. Retarget chat-fetch.sh's refusal in the same PR (reading needs a bearer; reporting does not), moving the three tests that pin that text. Repo/files: .github/.claude/session-start-dispatch.mjs, chat-fetch.sh, discoverability.test.mjs. Who: session-with-claim. Blocked on: step 8.

10. Make boot.sh merge ~/.claude/settings.json instead of overwriting it with a hooks-only document at every bare boot. This must land before the acceptance test, or the child's extra_allowed_tools grant can be erased at boot and the stall will read as "report_out does not work". Ship the verb payload and bump the pin in the same PR. Repo/file: .github/.claude/boot.sh:158-172, pin generator. Who: session-with-claim + owner-device (pin). Blocked on: steps 4, 9.

11. Acceptance measurement, not assertion. Spawn a bare child, permission_mode not plan, extra_allowed_tools ["mcp__bounded-verbs__report_out","mcp__bounded-verbs__read_session"] (entries the parent lacks are dropped silently), point it at a freshly claimed OPEN issue, and confirm: the channel statement appears in its context, the verb returns the door's success, the comment lands with its text. A red run means the fix does not exist, whatever the tests say. Then re-run #337's measurements 1–5, which are still unrecovered. Who: session-with-claim. Blocked on: step 10.

12. Transcript publishing (door c) — only if step 6 ruled yes, and only after three prerequisites. Every transcript publishable through this door contains, by construction, the session's own human_authorization claim token and any lease material redeemed at boot, because the door's gate is the claim that produced them. So: (a) a redaction gate covering at minimum that class, (b) a machine-executable deletion lane — "a hand-made raw API call under the org pat" requires a human holding PATHBASE_PAT in plaintext, which the no-laptop policy forbids, (c) a retention statement that admits a window cannot be observed through a door with no list verb. Only then publish-session.sh: BOUNDED_DOOR_PUBLISH (a new switch, not BOUNDED_PATHBASE_SHARE), --claim regex pinned pre-network, path p derive to a temp file, local maxBytes check, upload with curl not path p export (measured: the CLI errors on HTTP 200 and demands a UUID id on 201, and can never see x-door-claim/x-door-postback). Key the public/private trailer on the repo the trailer lands in, not the claim repo — cross-repo claims are normal. Also disarm the --anon trap in share-session.sh, which currently reads as forbidding the door recipe. Repos: infra/cloudflare/pathbase-door, .github/.claude/, .github-private/.claude/share-session.sh. Who: session-with-claim. Blocked on: step 6 and its three prerequisites.

13. Re-check the vendor-surface negatives properly, in the place they already live. Do not build a new ledger file + checker + test triple: the ten measured rows are already a table on #338, and .claude/findings.sh with its discharge <n> <url> field is the org's existing mechanism for exactly this class. Re-classify every agent-run negative as indeterminate until it carries a control fetch, correct api.claude.ai from "403" to "never reached — NXDOMAIN, two vantages, #56", restore the dropped ListMcpResourcesTool row and the measured positive that claude.ai/code/artifact/{uuid} is fetchable. Run HTTP probes from the live relay vantage (/claude/sessions, unauthenticated, measured 200), not a GitHub runner whose shared IP reintroduces the ambiguity. Repos: .github#338, .github-private/docs/handoffs/chat-relay.md, .claude/findings.sh. Who: session-with-claim. Blocked on: step 1.

14. File the artifact-surface successor and re-point #824. #823 is closed and contains no probe; do not reopen it. The successor's first probe is now the measured-fetchable claude.ai/code/artifact/{uuid} family plus a rendering_mode sweep on one control share, from the relay vantage, capped (one control chat, ≤10 requests, ≤1 run/week, no enumeration, ids only from the payload). Merge the unfiled vendor-drift tripwire into the same ticket. Repo: .github-private. Who: session-with-claim. Blocked on: step 13.

15. Send the vendor ask (#338 door a). Two questions: is any supported transcript read reachable from a session for a Code session URL, and — the lever — create_session's own tool description names list_events and send_message, which are absent from the surface: doc defect or unshipped capability? Publish at a stable URL so refusal-or-grant is linkable. guest-room is not checked out here; pick a reachable home. Who: owner-device, then vendor. Blocked on: step 13 (the contradiction record is the evidence).

16. Record the door (b) refusal where it belongs — .github-private#835 Phase 2, in writing, owner only. Note that #835 already records the custody objection and a brokered-lease containment story; the genuinely unrecorded objection is that a browser-born, account-wide sessionKey in the possession-only /lease tier collides with the broker README's own rule that keys whose theft touches org code never belong there. Also record that "(a) is taking too long" is true by construction and is never evidence for (b). Who: owner-device. Blocked on: nothing.

17. Hygiene, independent of everything above. ~/.relay-lease-bearer is mode 0644 and read with no mode check — write it 0600. Widen bounded.tools/.github/workflows/deploy.yml:181 so an approver is told the run may hand a relay bearer to a session. Widen the claim-ceremony consent text if step 12 ships (holding a claim would then permit a full transcript export). Give /lease its first recorded security review (grep -ci lease SECURITY.md is 0 while the tier is live, session-facing and possession-authenticated). Note in code, or pin by test, that LEASE_FORBIDDEN_SECRET_PREFIXES would not catch a future relay entry. Repos: .github, bounded.tools, infra. Who: session-with-claim; the consent texts are owner-visible. Blocked on: nothing.

18. Apply infra#564's ready patch to rotate-lease-key.yml, after settling the unowned operational fact: was PATHBASE_LEASE_SLOT_LAST ever hand-seeded to B, and does slot B hold an unrecorded key? Getting it wrong overwrites the newer key on the first post-patch rotation. Do not mirror bounded.tools#68. Also correct toolpath-pathbase.md's implication that run 31453454637 was green — chat-relay.md already carries the correction; the stale line next door does not. Repo: infra. Who: session-with-claim; the slot-B fact needs owner-device.

19. Tick .github-private#835 Phase 1 for #325/#326 (both closed and merged) and run the remaining Phase 1 work: the blind-agent A/B/C acceptance gate across created / resumed / subagent postures. This is the only honest test that the discoverability chain works. Who: session-with-claim. Blocked on: steps 4, 5, 10.

20. Auth-design mining backlog, in its own dependency order: infra#568 (the census fold) is the hub — it forces the attestation type set to declare itself; #569 emits the types it consumes; #567 supplies the tombstone/revocation primitive it must read; #570 bounds what silence in it means; #566-vs-#554 decides whether a claim in it is theft-resistant. #565, #571, .github-private#830, #831, bounded.tools#74, guest-room#80 are independent. None of these blocks or is blocked by steps 1–19. Who: session-with-claim, one claim per issue.

Dropped, explicitly

• The broker /lease "relay" tenant, entire. Two fatal verdicts, on independent grounds: no admissible holder exists for RELAY_LEASE_KEY_A/_B (/lease has no OIDC path, so an Actions lane needs it as a stored repo secret and a session needs the dialog paste — both forbidden); the blast-radius argument that justified tier eligibility is refuted by the chain itself (relay bearer → pathbase door → an issue comment authored by the front-desk App's installation token, i.e. GitHub write on org repos); LEASE_FORBIDDEN_SECRET_PREFIXES is applied to keySecret unconditionally and mode-independently, so "grant mode never releases it" is not the exemption the design treated it as; and grant mode fronts a third-party master, while here the org owns both ends. docs/handoffs/chat-relay.md's "Deliberately NOT built: a broker /lease/<name> tier for the relay" stands. If a session credential is ever needed, the recorded carrier is .github-private#545's: session dispatches a workflow, the workflow OIDC-mints and surfaces a single-use short-TTL pairing code in run output, the session redeems it. No lease key, no environment dialog, no append_system_prompt.
• The append_system_prompt carrier. Its only mitigation ("unset the code after redeeming") is unimplementable — a system prompt cannot be removed from a child's context or transcript.
• A read leg on the pathbase door. The absence of list/read/delete is the door's own named load-bearing control (a proxied read spends the pat's owner-level read power across every transcript in the account). No version of it may be gated on CLAUDE_RELAY_LEASES.
• The vendor-surface.probes.json + due-checker + test triple. Duplicates #338's table and findings.sh; its motivating premise ("these facts live only in a transcript") is false.
• Auto-publish / automatic per-spawn grants. No mechanism exists; as an instruction in a seed prompt it is unreliable by construction, and a Stop hook does not fire on a container kill.

3. Issue map

Issue	Where it lands
.github#337	Steps 1–3, 11. Stays OPEN until step 11 re-measures — closing it makes any claim on it 403 at the door. Not closed by the out-channel PR.
.github#338	Door (a) → steps 13, 15. Door (b) → step 16 (refused). Door (c) → step 12, and only if step 6 rules yes.
.github#270	Close as superseded. Scope item 1 (declare a .mcp.json) is already satisfied by #326; the live half is the auto-mode classifier denial — fold into #847 / #850 item 6.
.github#325, #326, #328, #318, bounded.tools#71	Closed and merged. No residue except the unmechanized blind-agent probe → step 19.
.github-private#514	Step 2. Cheapest, highest-leverage measurement in the plan.
.github-private#835	Step 19 (tick Phase 1, run the gate); Phase 2 → step 16; Phase 3 unfiled.
.github-private#847	Blocks step 4. Root gate for every ceremony-carrying step.
.github-private#848, #849	Step 4, one PR.
.github-private#839	Step 5 (item 1). Items 2 and 3 still unfiled.
.github-private#850	Item 6 blocks step 5; the board itself is not worked, it is read.
.github-private#525	Step 6, narrowed to the door target.
.github-private#545	Not re-parented, not duplicated. It is the standing precedent for any future machine-to-machine credential and supplies the carrier the bearer track lacked. Leave open.
.github-private#823	Stays closed. Do not reopen.
.github-private#824	Re-pointed at the successor filed in step 14; text half already done.
.github-private#830, #831	Step 20, independent. #831 self-flags its core mapping as unproven — design ticket, not ready-to-build.
infra#564	Step 18. Implementation-ready; carries an unowned operational fact.
infra#565, #567–#571	Step 20. #568 is the hub.
infra#554 vs #566	Owner decision (§4.7). No longer on any critical path once the bearer track is dropped — it bears only on the keeper ceremony.
infra#555	Close as a partial duplicate of #566, folded into whichever of #554/#566 survives.
infra#50 q2 (account-wide Workers Scripts:Edit)	Unchanged and unanswered; not worked here, but every deploy lane inherits it.
bounded.tools#74	Step 20, independent. Shares the "session gets something authenticated at start" leg — coordinate, do not duplicate.
bounded.tools#69	Merged but never executed. Not worked here; note that "the home-slot lane works" remains an inference from YAML.
guest-room#80	Step 20. Readable over the API; the repo is not on disk.
No issue exists for the broker-relay-bearer directive	Do not file it as designed. File a short decision record that the /lease relay tenant is refused on the evidence above, so the reversal question is closed rather than left open.

4. Decisions only the owner can make

1. May a bare session upload its own transcript through the pathbase door (private, org pathstash, claim-gated, vaulted pat) without BOUNDED_PATHBASE_SHARE=on? Options: (a) no — ship the upload-free findings route only; (b) yes, on request; (c) yes, by default. Recommend (a) now, revisit (b) after a redaction gate. (c) reverses share-session.sh's explicit "SHARE NOTHING, and it is not a placeholder to be relaxed later" and multiplies unredacted copies at a third party.
2. May the door carry caller-authored text into its testimony comment? Options: (a) yes, with a hard length cap, plain-text escaping and the existing ceilings; (b) no — testimony only, and accept that findings never reach the issue; (c) route findings through a broker /github/<app> door instead. Recommend (a). (c) needs OIDC, which a session cannot mint, so it does not serve this leg.
3. Given that every publishable transcript contains the session's own human_authorization claim token by construction, is a redaction gate a precondition for any upload? Options: (a) yes, block uploads until it exists; (b) no, accept and rotate the affected tokens. Recommend (a). Under (b) the acceptance test is itself an export of live org auth material.
4. Must a machine-executable deletion lane exist before the first live upload? Options: (a) yes; (b) accept "hand-made raw API call under the org pat". Recommend (a) — (b) requires a human holding PATHBASE_PAT in plaintext, which no-laptop forbids, so under (b) "we can delete" is a capability with no procedure.
5. Is .github-private#847 fixed before step 4, or do we accept a Face ID on this one pin bump? Options: (a) fix #847 first; (b) spend the tap once and proceed. Recommend (b) for step 4 specifically, (a) before any lane that must run unattended — #848 is a silent-failure bug and should not wait on a design.
6. Who sends the vendor ask, from which account, and where is refusal-or-grant recorded at a stable URL? #338 names chat-relay.md and assigns nobody. Recommend: owner sends it; the answer is recorded as a row in #338's table with the URL as evidence. guest-room is not available here.
7. PKCE (infra#554) or DPoP (infra#566) for sender-constraining the claim ceremony, and is infra#555 closed as a partial duplicate? Recommend: settle it, but off the critical path — with the bearer track dropped nothing in steps 1–19 depends on it.
8. infra#564: was PATHBASE_LEASE_SLOT_LAST ever hand-seeded to B, and does slot B hold an unrecorded key? Unverifiable through the session proxy. Recommend: answer before applying the patch — getting it wrong overwrites the newer key on the first post-patch rotation.
9. Do the Face ID consent texts get widened before the next grant run? bounded.tools/.github/workflows/deploy.yml:181 never names grant_relay_lease or rotate_relay_lease, so approvals are genuine but under-informed. Recommend: yes, before any further grant.
10. Should the pathbase-door note route's expanded capability get a recorded security review before merge? Recommend: yes — it turns a fixed-text testimony comment into a claim-gated arbitrary-text writer under the front-desk App's identity.

5. What this plan does not solve

• No channel IN. A claude.ai/code/session_<id> stays unreadable. Nothing here changes that; only step 15's vendor answer could, and it may never come.
• The #337 v1 session's findings are permanently lost. The session URL 403s, list_events/send_message are absent from the surface, get_session returns metadata only, read_session reads local files only. Nothing reaches backwards.
• Forward-only. boot.sh runs once, at session creation; a resumed session re-runs nothing. Every session created before a pin bump keeps the old payload forever. No session gains report_out retroactively.
• Opt-in. A child that crashes, is killed, exhausts context, or simply does not call the verb reports nothing. This is a channel, not a recorder.
• No identity. Nothing here gives a session a machine-verifiable identity. /session stays inert, SESSION_ISSUERS stays {} and pinned at 0 by the proofs corpus, the door attributes the claimant the issue names, and any bearer remains possession.
• Public repos stay degraded for transcript publishing: the door withholds the URL from public threads by design, so on .github the thread says something was uploaded and not what.
• Retention at the vendor stays unobservable. A window cannot be enforced or even measured through a door with no list verb, and building the read that would measure it is the control the door deliberately does not have.
• The claim ceremony still costs a Face ID, and pin bumps still block a runner until #847 lands. This plan reduces taps per grant to zero only by not issuing grants.
• No standing e2e for the relay or the door. The only door e2e is a single hand-run measurement; nothing re-asserts it.

6. Gaps — where silence is not coverage

• Nobody has measured a bare container. Whether path finishes compiling inside a child's life, whether pathbase.bounded.tools is on that environment's egress allowlist, and what a claim-less anon POST actually returns are all unestablished. The only session-side measurement of this surface on record is #545's 404 on every route. Step 3 exists because two designs asserted reachability as fact.
• create_session's carriers were never measured. environment_variables is documented as ignored for remote_cowork and unverified elsewhere; source_url (#514's repair) is explicitly UNVERIFIED; whether a GitHub MCP surface can be inherited by a child at all was never asked. Three designs reasoned from these as if settled.
• Every vendor-surface negative was taken without a control, through an agent proxy documented to return 403/405/407, on a host where the org has already measured that a 403 was the client's flavor and not the route's policy. By the org's own control rule these are indeterminate.
• No retrieval path was ever named for an uploaded graph. Private visibility, no URL on public repos, no read route on the door, ledger readable only via wrangler. "Who reads this and with what credential" is unanswered in all three publish designs.
• The redaction gate was never costed by anyone, and nobody noticed until adversarial review that the claim ceremony's own token is in every transcript by construction.
• Whether claude.ai/code/artifact/{uuid} fetchability extends to artifacts referenced from a share is unknown — the measured positive is for the Code surface, and the artifact probe was designed as if no positive existed.
• infra#564's slot-B state is unowned and unverifiable through the session proxy. Nobody has volunteered to establish it, and the first post-patch rotation depends on it.
• bounded.tools#69's home-slot grant lane has never executed. Its first real run will be the first grant_relay_lease dispatch — possibly during an incident.
• #337 measurements 1–5 remain unrecovered. Nothing in this plan asserts what a bare session's tool list contains; step 11 is the first thing that would.
• No survey established what #847 actually requires. It is named as the root gate for unattended work by #850, and its own text says the job is to replace the property run_id was providing — not move a step. Nobody has scoped that.
• #839 items 2 and 3 (settle context.md canonicity, cover the KV copy) do not exist as tickets, so the drift that recurred once can recur again.

Related: #337, #339.

---

Generated by Claude Code

[bdelanghe]

Step 13 done: the 403s are a Cloudflare bot challenge, host-wide. The table above is wrong.

Re-probed with controls, as the plan's own gaps section demanded. This retires the indeterminacy and replaces it with a different fact.

CONTROL  pathbase.bounded.tools/          405  (+ x-door-version)   egress works
CONTROL  example.com/                     000                       proxy allowlist blocks it
CONTROL  claude.ai/  (ROOT)               403  "Just a moment…"     <-- the finding
TARGET   claude.ai/code/session_<id>      403  "Just a moment…"
TARGET   claude.ai/api/claude_code/…      403  "Just a moment…"
POSITIVE claude.ai/code/artifact/<uuid>   200                       exempt from the challenge

Just a moment… is Cloudflare's managed-challenge interstitial. It is served for claude.ai/ itself — the bare root, no session, no API path.

What this means, precisely

Every "403" recorded on this issue measured one thing: that a non-browser client does not pass claude.ai's bot gate. Not that a session-read route is forbidden. Not that one does not exist. We never got far enough to ask the question.

Three corrections follow:

1. The per-path table was meaningless. code/session_<id> and three api/… shapes were listed as four independent negatives. They are one negative — the bot gate — repeated four times. The route beyond it was never reached.
2. It is not the agent proxy either. That was the workflow's hypothesis and it is also wrong. The proxy passes claude.ai (we get Cloudflare's own page from claude.ai's edge, not a proxy error), and it blocks example.com outright with 000. Two different failures that both had to be ruled out, and the control separates them.
3. The artifact positive is now the interesting row. code/artifact/<uuid> returns 200 through the same client, the same proxy, the same host — even for a bogus all-zeros UUID. So the challenge is path-scoped, and at least one path is deliberately exempt. That is a much stronger lead than "artifacts happen to be fetchable": something already distinguishes machine-reachable paths from browser-only ones on this host.

What it does to the vendor ask (step 15)

The ask cannot be "we get 403 on the session URL, is there a supported read?" — that describes the bot gate and invites the answer "use a browser."

It should be two questions, in this order:

1. Is there a supported programmatic path to a Code session's transcript at all — any surface, any auth — for the account that owns the session? create_session's own tool description names list_events and send_message; neither is exposed on the MCP surface. Doc defect, or unshipped?
2. code/artifact/<uuid> is exempt from the challenge that covers the rest of the host. What makes a path exempt, and is that mechanism available to a read route? This is the concrete lever, and we now have the evidence to point at.

Where the record stands

.github#337's comments repeat the old table and should be read against this one. The session URL is still not readable — that conclusion survives — but the reason in every prior comment is wrong, and the reason is what the vendor ask depends on.

Door (b) stays refused; nothing here changes that. If anything this weakens it further: a credential-bearing relay tier would still face the same bot gate unless it also solved the challenge, which is squarely the thing we said we would not build.

---

Generated by Claude Code

[bdelanghe]

The measurement this issue was waiting on — #372

This asks for a Claude Code session URL to read like a share link. The read matrix (#372) now says exactly what exists and what does not, measured 2026-09-03:

you have	you get today
a claude.ai/share/<uuid> link	✅ full transcript, paginated, via mcp__bounded-verbs__read_chat
a session on this disk	✅ full transcript via mcp__bounded-verbs__read_session
a claude.ai/code/session_<id> URL for another machine's session	❌ nothing — read_session answers not found on this machine, correctly: it reads ~/.claude/projects and nothing else
the same session's metadata	✅ CCR get_session — title, status, model, cost, task summary, but no turns

So the gap this issue names is real and precisely bounded: metadata crosses machines, turns do not. The verb is not missing a URL parser; it is missing a transport, and the transport is the interesting part.

Worth stating because it changes what "implement this" means: read_code_session is not a small wrapper over read_session. Either the target session's disk is reachable (it is not), or something must have published its transcript somewhere the reader can reach — which is the toolpath/pathbase direction, and which makes this issue a consumer of that work rather than a sibling of it.

One thing measured tonight that makes it cheaper than it looks: read_session mode=graph already emits the toolpath Graph, and the door's maxBytes (33,554,432) comfortably fits a full day's session (this one: 8,044,231 bytes). The producer and the pipe both exist. What is missing is the publish step and a claim to publish under — plus #371, because graph mode currently cannot be windowed at all.

---

Generated by Claude Code