The read matrix: what a session can and cannot read, measured — and the four gaps

[bdelanghe]

Why this issue exists

#337 measured what a session can do (the posture matrix). Nothing measured what a session can read, and the question keeps recurring — it is the one this whole arc started from: "can we read our own Claude mobile chat sessions through any api or mcp?"

Every row below is a real call made on 2026-09-03 from this session, after #343 closed. This is the index; the gaps have their own issues.

The matrix

what	route	result
own session, latest turns	mcp__bounded-verbs__read_session (no args)	✅ turns 703–705 of 705
own session, from turn 1	read_session session_id=… offset=0	✅
own session, Graph JSON	read_session mode=graph	❌ #371 — 8MB for a 2-turn window; offset/limit ignored
inside a subagent, no args	read_session	⚠️→✅ returns the PARENT's transcript and now says so — #343 fix 2 verified from a child
inside a subagent, explicit id	read_session session_id=…	✅ clean label
another Claude Code session, transcript	read_session session_id=<remote>	❌ not found on this machine — correct by design; the verb is local-disk only
another Claude Code session, metadata	CCR get_session	✅ title, status, model, cost, task summary
shared chat, live	read_chat	✅ 112 turns, paginated, offset=-3 works
shared chat, unshared/revoked	read_chat	✅ relay returns a clean 404 "not (or no longer) shared" — a real vendor answer, not a transport failure
own artifact	Artifact read	✅ 30.9KB, saved to disk
own artifacts, enumerate	Artifact list	✅
artifact comments	Artifact comments	✅ (none posted yet)
unshared mobile chat	—	❌ the original question. No route exists.
artifact shared with you	Artifact read	◻️ untested — none exist to test against

The four gaps, each findable

1. read_session graph mode returns 8MB for a 2-turn window — offset/limit are ignored #371 — read_session mode=graph ignores offset/limit and returns the whole session.
2. Unshared chats have no route. Not a bug and not fixable by us: the relay reads only public shares and holds no vendor credential. This is the standing answer, and Vendor ask: is there a supported programmatic read of a Claude Code session transcript? #348 is the vendor ask that would change it.
3. Remote session transcripts. CCR gives metadata; read_session gives turns but only for this disk. Nothing gives another machine's turns. Whether that should exist is a design question — the door model says a session reading another session's transcript is a capability someone must grant.
4. Artifacts shared with you are untested because none exist. Worth a probe the next time one does, rather than assuming the documented summary mode works.

The direction, recorded

The maintainer's stated intent (2026-09-03) is that this all moves onto toolpath and pathbase — the read verbs become Graph producers, and the door is how a session reaches them. read_session mode=graph is already that shape, which is why #371 matters more than its size suggests: it is the seam where the transcript stops being prose and starts being data another room can consume.

Related: #325, #326, #337, #343, #348, .github-private#514.

Not claimed.

[bdelanghe]

Toolpath / pathbase readiness — measured, and the one missing piece

The stated direction is that all of this moves onto toolpath and pathbase. Here is how close it already is, measured rather than assumed.

Present:

piece	state
path CLI	✅ 0.16.1 at /root/.local/bin/path
the Graph itself	✅ read_session mode=graph produced 8,044,231 bytes for this session — under the door's maxBytes (33,554,432) with room to spare
the door's upload route	✅ reachable — POST /c/<repo>/<issue>/api/v1/u/anon/repos/pathstash/graphs
egress to the door	✅ three curl calls permitted in the canonical URL-first form

Missing: a live claim. That is the whole gap, and it is by design — the door's unit of authorisation is a claimed issue.

The refusal taxonomy, probed live

Three requests, three different and correct answers:

unclaimed open issue (#372)  → 403  no `claimed` label — claim before sharing (claim-ticket.yml)
closed issue (#343)          → 403  issue is not open
wrong repo segment           → 403  issue unreadable (404)

Each names what is actually wrong. That is worth recording because #342's complaint about the classifier is the exact opposite — this door tells you which door you are at.

One security property, confirmed by accident

I sent a note containing a forged claim marker (<!-- claim-ticket --> plus a **Claimed** by line) at an unclaimed issue. The response was the claim refusal, not a sanitiser refusal — meaning the claim check fires before the note is examined at all. The sanitizeNote fixed point (infra#577) is defence in depth behind a cheaper check that already stopped this. Correct ordering; nice to see rather than infer.

What a full end-to-end still needs

One passkey tap on any issue, then PATHBASE_URL=… path p export pathbase --anon --input <graph> through the door. The graph is on disk and the CLI is installed, so it is a single ceremony away — not a build.

One thing I cannot attribute

This session booted before #367, so its ~/.claude/settings.json does not carry the new allowlist rule. The three curl calls were permitted anyway. So tonight's grant is not what allowed them, and I have no measurement proving the rule works — only that this shape of request was permitted here. The first bare session to boot on channel v13 is the real test, and #337's probe method is how to run it.

---

Generated by Claude Code

[bdelanghe]

Discoverability audited across all three checkouts — the docs are right, the reach is the problem

Every claim below cites file:line. Two findings are fixed in #375; the rest are open and listed so they are findable.

Fixed in #375

• discoverability.test.mjs:245-253 could not catch context: name the verbs with their prefix, because the bare names do not resolve #346. assert.match(ctx, /read_chat/) is satisfied by the bare name — the very text context: name the verbs with their prefix, because the bare names do not resolve #346 removed. The gate would have passed the defect it exists for. Now derives mcp__<server>__<tool> from .mcp.json:3 + verb-server.mjs:74/:94 and asserts context.md contains it, for both verbs. Negative control run.
• read_session was never checked in context.md at all. Delete every mention and the suite stayed green — for the verb with no fallback script.
• boot.sh:206-217's cache declaration was unchecked. A checkout-less session composes its tool name from that key, not the repo's. Drift there is wrong for exactly the population the bullet was written for.

The real problem, unfixed: the correct doc is the one a resumed session never sees

where	mentions of the capability
.github/CLAUDE.md	0
.github-private/CLAUDE.md	0
infra/CLAUDE.md	0
.claude/README.md (653 lines)	0 in its inventory — README.md:3-12 says "Six files here" and omits verb-server.mjs and chat-fetch.sh; the directory holds 40
docs/handoffs/chat-relay.md	0 — :211-228 still titles its consumer section "the consumer: chat-fetch.sh", a generation stale
adopt-claude-harness.sh:339-378	0 — and this block reaches ~84 repos

Both CLAUDE.md files open by declaring themselves the only org channel that survives a resumed session (.github/CLAUDE.md:2-6). So the one document a resumed session is guaranteed to read is the one that never names the verbs.

Shortest path today, measured:

• .github attached and the org context hook fired → claude/context.md:60-73, one hop. That bullet is excellent and is the single load-bearing artifact in the system.
• No checkout → still works: inject-org-context.sh:122-126 fetches public-context.md from the boot Worker anonymously, boot.sh:165-217 lands the verbs. Both halves measured.
• Hook did not fire → no path at all. infra/CLAUDE.md:30-33 tells the session it is in degraded mode and to stop.

Parity is enforced from one side only

.github-private/.claude/context-parity.sh:33-53 fetches the .github copy and compares. There is no reciprocal check in .github — discoverability.test.mjs:40 scopes to the .github copy alone. Not theoretical: #346 merged green in .github and turned .github-private's gate red on every unrelated PR for 43 minutes until 6ccccb9, whose message records this as "third recurrence of the drift #839 tracks, and the first in the OPPOSITE direction."

Byte-identity right now: identical, 6042 bytes, 4881529c…, and boot.bounded.tools/public-context.md serves the same hash. All three copies agree and carry the #346 text.

One trap still live

The share-page / snapshot-API warning exists in exactly two places: context.md:71-72 and the tool descriptions. chat-relay.md:42-49 documents the vendor snapshot endpoint neutrally, noting only that a session cannot reach it — a reachability statement, not a prohibition — and :104-125 narrates the bot-gate investigation as solved. That is a plausible re-entry point into the exact 2026-08-31 failure the whole chain was built against.

Ranked, for whoever picks this up

1. adopt-claude-harness.sh:339-378 — one line, ~84 repos. Highest leverage available.
2. .github/CLAUDE.md + .github-private/CLAUDE.md — one line each, the resume-survivable channel.
3. chat-relay.md:211-228 — promote the verbs, demote the script, add the prohibition near :42-49.
4. .claude/README.md:3-12 — the "six files" table is wrong and omits both files this is made of.
5. Reciprocal parity check in .github, or extend discoverability.test.mjs:40 to both copies.

Not claimed.

---

Generated by Claude Code

[bounded-systems-front-desk]

🎫 Claimed by claude-session-01TzRQgn — 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): 017169791bb59abb8ce8107513f6669d29e3852b19846247c9c0b87b97f517ae · base64url AXFpeRu1mruM6BB1E_ZmnSnjhSsZhGJHycC4e5f1F64

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