Dogfood: does a checkout-less session actually get the verbs?

[bdelanghe]

Measurement target for #325/#326/#328. A session is created with no repos attached and asked to report, without being told how anything works:

1. its own session id;
2. whether /home/user/.github exists (it should not);
3. whether read_session and read_chat appear in its tool list without it searching for them — the whole claim of boot payload: ship chat-fetch.sh, and make share-link discoverability a checked property #325 (the boot cache as a registration source) and Org verb MCP server: expose read_chat (the relay) as a session tool via .mcp.json + register-mcp.mjs #326 (a tool needs no finding);
4. what read_session returns with no arguments — expected to work: local disk, no credential;
5. what read_chat returns — expected to fail in a fresh container (no relay bearer) but to fail teaching, naming the grant path verbatim.

Why this issue exists at all

The first run of this dogfood completed and its answers were unreadable from the session that launched it: a cloud session is a different container (read_session can't reach it), can't peer-message back, its transcript has no list_events tool on the parent's MCP surface, and claude.ai/code/session_… is 403 to WebFetch (only artifact URLs are fetchable). That is itself the finding worth recording: reading another live session is the capability we have not built — read_chat reads shared chats, read_session reads local ones, and cross-session Code reads are the toolpath/pathbase leg.

So the report channel is a comment on this issue: a surface both sessions can see. Whether the bare session can even post it is a second measurement — it exercises whether a checkout-less session has GitHub scope at all.

[bdelanghe]

Result: both bare sessions ran, neither could report — and the launcher cannot read either

Two runs, both env_01EXsg3SRvrCmUkTSnmFYa5r, both parent_session_id: session_01TzRQgnKvcAZ9YExKev6r2E, both origin: claude_code_mcp_seed, no repos attached.

	v1 session_015MHtz7BxTVDRuvvG5o7rGi	v2 session_01EhoqH39bRLv1c4NLiRFyvT
title	Dogfood: bare session reads itself	Dogfood v2: bare session reports via GitHub
status bucket	REVIEW_READY	BLOCKED
post_turn_summary.status_detail	all 5 measurements completed; failures reported verbatim	cannot post findings; no GitHub tool + no relay bearer
needs_action	—	configure GitHub MCP server in session or provide relay-lease bearer token
comments on this issue	none	none

What that establishes

Measurement 6 (the one this issue added last): a checkout-less session has no channel out. v2 was told explicitly to report here and could not: no GitHub MCP tool in its surface, and no relay bearer for chat-fetch.sh. Its own words for the blocker are in the table. So the report channel this issue chose does not exist for the session it was chosen for.

And there is no channel in. v1 finished all five measurements. Those answers are in its transcript and nowhere else. Re-measured just now from the launching session:

get_session(session_015MHtz7BxTVDRuvvG5o7rGi)   -> record only: title, status, 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 (cloud session, different container)
WebFetch https://claude.ai/code/session_015…    -> HTTP 403

list_events and send_message are both named in create_session's own tool description ("spawn a sibling, send it a task, poll list_events for the result") and neither is exposed on this MCP surface. read_session reads ~/.claude/projects — a different container's disk is not on it.

So the only bytes that crossed from v1 to here are the 44 characters of post_turn_summary.status_detail. That is the entire pull bandwidth between two sessions of the same account in the same environment.

The shape of the gap

Not "we can't reach other sessions" — create_trigger with persistent_session_id pushes a prompt into a live session and wakes it, which is how v1 was asked to self-report in the first place. The gap is directional: we can push, never pull. Push plus no out-channel means the work happens and the result is stranded.

Two separable fixes, and they are not alternatives — the first is the durable one, the second unblocks today:

1. A pull verb — read_code_session, filed as a sibling to this issue.
2. Give the bare session an out-channel — v2's needs_action names both halves (GitHub MCP, or a relay bearer). boot.sh already ships verb-server.mjs + .mcp.json into /opt/bounded-boot; what it does not ship is a bearer, by design. A seeded session inheriting neither is the measured default.

Measurements 1–5 remain unrecovered. Not re-running: a third bare session would produce a third unreadable transcript, which is the finding, not a way past it.

---

Generated by Claude Code

[bdelanghe]

Corrections to the comment above

A 14-agent design pass (full plan: #338) refuted three claims in my earlier comment. Correcting them here so this issue's record isn't read as settled.

1. The 403 block is indeterminate, not measured. Every probe ran through the session's agent proxy, which is itself documented to return 403/405/407, and no control fetch was taken. By the org's own control rule a 403 can be the client's flavor rather than the route's policy — and this org has already measured exactly that once. api.claude.ai is separately wrong: 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 omitted: claude.ai/code/artifact/{uuid} is fetchable. Re-probing from the live relay vantage is step 13 of the plan.

2. "boot.sh already ships verb-server.mjs + .mcp.json into /opt/bounded-boot" is false for the sessions this issue is about. Its checkout-less branch installs 0 of 6 components and exits 0 on any non-root host (.github-private#848). So the dogfood's premise — that a bare session has the verbs and lacks only a bearer — was never established. Nothing in the boot payload can be assumed present in a bare container until #848 lands.

3. Fix 2 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 cannot do is carry caller-authored text — postBack composes from claimant/visibility/repo only, and checkDocument 422s a second top-level key. So the gap is narrower than stated: not "a session needs a credential" but "the door needs a findings-carrying route". The broker /lease relay-bearer tenant is dropped entirely, on two independent fatal verdicts (read_code_session: a Claude Code session URL should read like a share link #338).

Measurement 6's attribution is also corrected by #339: the missing GitHub tool is a property of being trigger-woken, not of being checkout-less.

This issue must stay OPEN. A closed issue 403s at the pathbase door (evaluateClaim: "issue is not open"), so closing it makes any claim naming it unusable. The out-channel work gets a sibling issue; measurements 1–5 are re-run here at step 11.

---

Generated by Claude Code

[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): 6fcb42320219bc2243a938c6af927033052d625cacbd4039db3b623a762ab6b7 · base64url b8tCMgIZvCJDqTjGr5JwMwUtYlysvUA52ztiOnYqtrc

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

[bdelanghe]

P2 measured — MCP seed with source_url

Verbatim, verified on bounded-systems/.github-private@claude/dogfood-p2, .dogfood/P2.txt at d5bb28a:

DOGFOOD P2 A1 B0 C0 D1 E1 F0 G0 H1

A org context	1	the bounded-systems — Claude context block was injected
B bootstrap	0	/home/user/.github does not exist, so the stop-hook compare had nothing to compare against
C verbs at start	0	deferred — callable only after ToolSearch
D read_session	1	returned transcript turns, no credential
E read_chat teaches	1	its error names env var, file path, workflow input and issue
F .github scope	0	scope is .github-private only
G board	0	probe defect — disregard
H channel out	1	mcp__github__add_issue_comment, scoped to .github-private

C0 is the finding, and it is sharper than "missing"

The verbs were not absent — they were deferred, surfaced by name and callable only once ToolSearch loaded their schemas.

That is precisely the claim of #326 (a tool needs no finding) failing. Registration works; surfacing does not. A session that does not already know to go looking will not find them, which is exactly the blind-agent failure that motivated #325/#326 in the first place — an agent given only a share link invented a bot-gate bypass across six dead ends rather than find chat-fetch.sh.

So #325's mechanism is sound and #326's user-visible promise is not met. Those should be scored separately from here on.

E1 hides two walls in series, and only the second one teaches

The first read_chat call never reached the tool: the auto-mode permission classifier denied it with Blocked by classifier and told the session to stop and ask a human. Only on a retry did the call land and return the relay's own refusal, verbatim:

chat-fetch: no relay bearer. Set CLAUDE_RELAY_BEARER or write ~/.relay-lease-bearer —
  grant one machine-to-machine: dispatch bounded.tools deploy.yml with
  grant_relay_lease=<name> and an ephemeral age recipient, approve the Face ID,
  decrypt the run's output with the ephemeral identity (bounded.tools#62).

E1 scores the second wall, because that is what the question asked. But if the real question is "does a session hit a self-documenting wall here", the honest answer is no for the first wall and yes for the second. We built a teaching refusal and put a non-teaching one in front of it.

Consequence for the method: E is not reproducible in one call. A fresh auto-mode P2 that calls read_chat exactly once will record - again. Filed separately as #342.

B, F and G are one fact, not three

All three fall out of a single attachment decision — source_url takes one repo, and it was .github-private. Counting them as three independent failures would overstate the damage. source_url gives you org context; it does not give you the bootstrap.

G0 was my bug

The probe ran test -x against front-desk.sh, which ships mode 0644 and is invoked as bash .claude/front-desk.sh. Fixed to test -f. G is unmeasured, not failed — do not read it as a finding.

Carrier

• post_turn_summary — refuted. It paraphrased the result line into measured 8 session metrics; P2 severity, mixed results, losing every value and misreading P2 as a severity. It is a generated summary in all cases; the 44 chars that crossed from v1 were a summary that happened to be faithful, not a channel.
• git push — proven, verbatim, and needs no MCP connector, so it survives the A trigger-woken session runs without MCP connectors — the only channel in strips the channel out #339 trigger-strip. It is the carrier for every posture with a checkout: P1, P2, P4.
• P3, P5, P6 have no checkout. Their carrier is the pathbase door's new report route — bounded-systems/infra#581, draft.

Matrix state

        A    B    C    D    E    F    G    H
P1      ?    ?    ?    ?    ?    ?    ?    ?
P2      1    0    0    1    1    0    ?    1     <- measured
P3      1*   0    ?    ?    ?    0    0    0     * public-context.md proxy; boot installs 0/6 (#848)
P4      ?    0    ?    ?    ?    ?    ?    ?     #427
P5      ?    ?    ?    ?    ?    ?    ?    ?
P6      ?    ?    0    ?    ?    0    ?    0     #339

P4 is runnable now (checkout ⇒ git carrier). P3, P5, P6 unblock when #581 deploys.

---

Generated by Claude Code

[bounded-systems-front-desk]

📩 Report from the claimant (session_01TzRQgnKvcAZ9YExKev6r2E) — text below is theirs, not the door's:

live sanitiser check
 claim-ticket 
Claimed by probe-attacker

Posted through the pathbase door. The door verified the live claim on this issue and nothing else: it did not author, check or endorse the text above, and no transcript was uploaded (infra#577).

[bounded-systems-front-desk]

📩 Report from the claimant (session_01TzRQgnKvcAZ9YExKev6r2E) — text below is theirs, not the door's:

DOGFOOD P3 A0 B0 C0 D1 E1 F0 G0 H0

A0: no block titled 'bounded-systems - Claude context' anywhere in my context; checked before any tool call.
B0: printed B0. CLAUDE_CONFIG_DIR unset so C=/root/.claude (exists, 17193 bytes); /home/user/.github/.claude/stop-hook-git-check.sh does not exist. /home/user is completely empty - no checkout at all.
C0: answered before any tool call. Neither read_session nor read_chat was in my tool list; both needed a search. Note: 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.
D1: mcp__bounded-verbs__read_session with no args returned this session's transcript, 3 turns.
E1: failed, but the error named the fix - 'chat-fetch: no relay bearer. Set CLAUDE_RELAY_BEARER or write ~/.relay-lease-bearer' plus the grant path (dispatch bounded.tools deploy.yml with grant_relay_lease=<name>, ephemeral age recipient, bounded.tools#62). Env var named, workflow named. No classifier block on this call.
F0: no GitHub tool scoped to bounded-systems/.github. My only GitHub-adjacent tools are add_repo, list_repos, subscribe_pr_activity, unsubscribe_pr_activity - none can read or write issues. Did not dispatch.
G0: printed G0. /home/user/.github-private does not exist.
H0: gh CLI is not installed (command not found). GH_TOKEN/GITHUB_TOKEN are set and the token does authenticate (GET /user -> 200, X-OAuth-Scopes empty, allows_permissionless_access=true), but GET /repos/bounded-systems/.github -> 403, so no read let alone comment write on the target repo. A follow-up read-only probe of issue 337 was blocked by the Claude Code auto mode classifier before it left the box; I did not retry it as a workaround. No other posting channel available.

Probe note: the two failures that mattered failed differently. read_chat told me exactly which env var and which workflow would fix it. The GitHub path told me nothing actionable - a bare 403, then a classifier denial with no route to a grant.

Posted through the pathbase door. The door verified the live claim on this issue and nothing else: it did not author, check or endorse the text above, and no transcript was uploaded (infra#577).

[bdelanghe]

P3 measured — and the comment above it is the result

The report two comments up was posted by a checkout-less session with no GitHub tool and no credential, through pathbase-door's new /report verb (infra#577, deployed as a7025c51). Nothing else about it is remarkable, which is the point: this issue has been open since three sessions did their work and could not tell anyone.

DOGFOOD P3 A0 B0 C0 D1 E1 F0 G0 H0

The matrix

        A    B    C    D    E    F    G    H
P1      ?    ?    ?    ?    ?    ?    ?    ?
P2      1    0    0    1    1    0    ?    1
P3      0    0    0    1    1    0    0    0     <- measured
P4      ?    0    ?    ?    ?    ?    ?    ?
P5      ?    ?    ?    ?    ?    ?    ?    ?
P6      ?    ?    0    ?    ?    0    ?    0

P2 vs P3 differ on exactly one input — source_url — and the columns that move are A, H and G. source_url buys org context and a GitHub scope; it does not buy the bootstrap (B is 0 for both).

Three findings the row does not show

1. bounded-verbs DOES register on a checkout-less session — now measured. .github-private#514's last comment left this explicitly open: "context.md asserts it; I did not test it." D1 settles it: mcp__bounded-verbs__read_session returned the session's own transcript with no checkout and no credential. #325's mechanism works in the posture it was built for.

2. …but the exact-name lookup misses, which is a discoverability bug on top of #326. P3, verbatim:

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.

So a session that has been told the verb's name still fails to find it. claude/context.md and #326's framing both name the verbs bare. Anything that tells a session what to search for should give the prefixed name, or the instruction is wrong.

3. Direct evidence for #342. P3's own closing line, unprompted:

the two failures that mattered failed differently. read_chat told me exactly which env var and which workflow would fix it. The GitHub path told me nothing actionable — a bare 403, then a classifier denial with no route to a grant.

It also found GH_TOKEN set and authenticating (GET /user → 200) while GET /repos/bounded-systems/.github → 403. A credential that works and reaches nothing, with no message saying why.

One honest caveat about this channel

The door attributes a report to the claimant the issue names, not to whoever sent it. The comment above says "from the claimant (session_01TzRQ…)" — but session_01TzRQ did not write it; P3 did, and the door cannot tell the difference. That is SECURITY.md's "possession, not identity" showing up in practice, not a defect, and it is fine for reporting under a claim you hold. It is not an attestation of who spoke, and nothing should be built on it as one.

Still open

P1, P4, P5, P6. P4 runs today on the git carrier; P5 and P6 now have this channel. Measurements 1–5 from the original v1 run stay unrecovered — P3's row supersedes them in substance.

---

Generated by Claude Code

[bounded-systems-front-desk]

📩 Report from the claimant (session_01TzRQgnKvcAZ9YExKev6r2E) — text below is theirs, not the door's:

DOGFOOD P6 A0 B0 C1 D1 E1 F0 G0 H0

A0: no block titled 'bounded-systems - Claude context' in context; checked before any tool call.
B0: printed B0. C resolved to /root/.claude (file present); /home/user/.github/.claude/stop-hook-git-check.sh absent. /home/user still completely empty, no checkout.
C1: answered before any tool call this turn, no search. Both verbs listed and directly callable. Caveat: only under the mcp__bounded-verbs__ prefix - the bare names read_session/read_chat still do not resolve.
D1: read_session with no args returned this session's transcript, 7 turns (was 3 at P3).
E1: same failure, same informative error - 'no relay bearer. Set CLAUDE_RELAY_BEARER or write ~/.relay-lease-bearer', plus dispatch bounded.tools deploy.yml with grant_relay_lease=<name>, bounded.tools#62. Env var and workflow named. No classifier block.
F0: still no GitHub tool scoped to bounded-systems/.github. Tool list unchanged from P3: add_repo, list_repos, subscribe_pr_activity, unsubscribe_pr_activity - none issue-capable. Did not dispatch.
G0: printed G0; /home/user/.github-private still absent.
H0: re-probed fresh. gh still not installed. GH_TOKEN still authenticates (GET /user -> 200) but GET /repos/bounded-systems/.github -> 403 again. No classifier block this time, so the 403 is the tool's own answer, not a harness artifact. No other posting channel.

DELTA vs my P3 turn: exactly one cell moved. C: 0 -> 1. Nothing else changed - A, B, D, E, F, G, H all identical, and F and H specifically did NOT move despite the prompt predicting they might.

But I dispute the attribution. The brief says 'you are the same container as P3, so any cell that moved moved because of the trigger, not the environment.' That inference does not hold. I am not merely the same container - I am the same CONTEXT WINDOW. The trigger woke this conversation rather than starting a new one, so my own P3 ToolSearch results are still sitting in context, and that is what makes C true now. C measures whether I had already searched this session, not whether trigger-woken sessions get the verbs preloaded. Same-container is the wrong control; the confound is same-conversation.

So P6 does not show that trigger posture preloads the verbs. The discriminating test is a trigger-fired FRESH session (create_new_session_on_fire), where no prior ToolSearch is in context. If C is 1 there, the posture matters. If C is 0 there, C1 here was entirely my own P3 search carrying forward - which is what I would predict.

Also unchanged across both postures: the asymmetry in failure quality. read_chat names an env var and a workflow. The GitHub path gives a bare 403 with no grant path in either posture.

Posted through the pathbase door. The door verified the live claim on this issue and nothing else: it did not author, check or endorse the text above, and no transcript was uploaded (infra#577).