Vendor ask: is there a supported programmatic read of a Claude Code session transcript?

[bdelanghe]

The linkable home for the question #338 door (a) and #342 both reduce to. Ready to send; not yet sent. The answer — grant or refusal — gets recorded here, so it is citable instead of living in a transcript.

The ask, in two questions

1. Is there any supported programmatic path to a Claude Code session's transcript, for the account that owns the session?

create_session's own tool description says, verbatim:

Combine with send_message for fan-out orchestration: spawn a sibling, send it a task, poll list_events for the result.

Neither list_events nor send_message is exposed on the MCP surface we can see. ToolSearch select:…__list_events and …__send_message both return No matching deferred tools found. get_session returns a record — title, status, timestamps, usage, post_turn_summary — and no turns, though its own reply envelope is labelled "record, transcript events, or run log".

So: doc defect, or unshipped capability? Either answer is useful. If the loop that description names is meant to close, list_events is the missing half.

2. claude.ai/code/artifact/<uuid> is exempt from a bot challenge that covers the rest of the host. What makes a path exempt, and could a read route be?

This is the concrete lever, and it took a control to find.

The evidence, measured with controls

Earlier probing recorded four separate 403s and concluded the session route was forbidden. That was wrong and is corrected on #338. Re-run with controls:

CONTROL  pathbase.bounded.tools/          405 (+ x-door-version)   our egress works
CONTROL  example.com/                     000                      proxy allowlist blocks it
CONTROL  claude.ai/  (ROOT)               403  "Just a moment…"    <-- Cloudflare challenge
TARGET   claude.ai/code/session_<id>      403  "Just a moment…"    same page
TARGET   claude.ai/api/claude_code/…      403  "Just a moment…"    same page
POSITIVE claude.ai/code/artifact/<uuid>   200                      exempt, even for an all-zeros UUID

Just a moment… is Cloudflare's managed-challenge interstitial, served for the bare root. So every 403 measured one fact — a non-browser client does not pass the bot gate — not four route policies. Nothing beyond the gate was ever reached, which is why question 1 is genuinely open rather than already answered "no".

The artifact row is the interesting one: same client, same proxy, same host, and it returns 200. Something already distinguishes machine-reachable paths from browser-only ones there.

Why we are asking rather than building

The alternative is a relay tier holding a browser-born credential, which is refused (.github-private#835 Phase 2, restated on #338). The corrected evidence weakens it further: such a tier would still face the same challenge unless it also solved it, and solving a bot gate is precisely the thing we said we would not build. "The ask is taking too long" is true by construction and is never evidence for building it.

What we can already do, for context on scope

• shared chats: read end to end (relay → toolpath Graph → pathbase door), deployed
• a session's own transcript: read locally, no credential
• a session reporting outward: built and deployed (infra#577), proven from a checkout-less session
• reading another live session: nothing. Push works, pull does not exist.

We are not asking for a new capability surface. We are asking whether one already exists that we have not found, and if not, whether the path-exemption mechanism in question 2 is available.

Sending it

Owner sends; the account matters and this session cannot speak for it. When an answer comes back, record it as a row here with a link, so #338 step 15 and #342 can both discharge against it.

Related: #338 (door (a), and the corrected 403 table), #342 (the classifier names no route — same message, different wall), #337 (the postures this was measured across), .github-private#835 (door (b), refused).

[bdelanghe]

Correction before sending: question 2's lever is weaker than the issue body claims

The body says claude.ai/code/artifact/<uuid> returning 200 shows "something already distinguishes machine-reachable paths from browser-only ones." Probed further, and that overstates it.

A real artifact — one a cold-start probe published tonight:

/code/artifact/f2bd5b8b-…      200   15,006 bytes
   -> visible text: "Claude Artifact  Content is user-generated and unverified."
   -> the shell references "/api/frame/<uuid>"; content is client-rendered

/api/frame/f2bd5b8b-…          403   "Just a moment…"
/api/frame/f2bd5b8b-…/content  403   "Just a moment…"
/api/frame/f2bd5b8b-…/latest   403   "Just a moment…"

The exemption covers the static HTML wrapper, not the data. The content endpoint is challenged exactly like everything else. So the 200 is not evidence that a machine-readable route could be similarly exempted — it is evidence that a shell with no content in it is cheap to serve.

This is the same shape as the share page (client-rendered SPA shell — already recorded in context.md and #325), reached from a different direction. I should have checked before treating a 200 as a reachable surface; a status code is not a payload.

Revised question 2

Not "what makes a path exempt, and can a read route be?" — that presumes an exemption worth having. Instead:

Every content-bearing path we can find is behind the bot challenge, including the artifact data endpoint whose own shell is not. Is there any supported way for a program acting for the account to read its own data — an API host, a token-authenticated route, anything — or is a browser session genuinely the only client?

That is a cleaner question and it does not rest on a misread.

Question 1 is unaffected

list_events / send_message being named in create_session's own tool description while absent from the MCP surface stands on its own. It needs no reachability argument — it is a documented capability that is not there.

One thing this does strengthen

The refusal of door (b) gets firmer again. A relay tier holding a browser-born credential would face the challenge on every content path, so it would have to solve the bot gate to be useful at all. That was already the objection; it is now measured rather than predicted.

---

Generated by Claude Code

[bdelanghe]

Send-ready text

Copy-paste. Written to stand alone — a reader outside the org needs no context from this repo. Corrected per the comment above: the artifact "exemption" is only the SPA shell, so it is not used as a lever.

---

Subject: Is there a supported programmatic read of a Claude Code session transcript?

We build agent tooling on Claude Code and run a lot of spawned/child sessions. We have one gap we cannot close from our side, and before building around it we would rather ask whether we have simply missed the supported path.

The question: is there any supported way for a program acting on behalf of an account to read the transcript of a Claude Code session that account owns?

What we can already do, so the scope is clear: we read shared claude.ai/share/<uuid> chats, and a session reads its own transcript from local disk. What we cannot do is read another session — including a child session we spawned ourselves, which is the case that actually bites us. We can push a prompt into a live session and wake it; we cannot pull anything back.

Two specifics we would appreciate a steer on:

1. create_session's own tool description names tools that are not on the surface. Verbatim from the description we are served: "Combine with send_message for fan-out orchestration: spawn a sibling, send it a task, poll list_events for the result." Neither list_events nor send_message is exposed to us — an exact-name tool lookup for both returns "no matching tools found". get_session returns a record (title, status, timestamps, usage, a short status summary) and no turns, although its own response envelope is labelled "record, transcript events, or run log". Is that a documentation defect, or a capability that exists and we lack?

2. Everything content-bearing is behind a bot challenge, so we cannot even ask the route. From a non-browser client, claude.ai/ itself returns 403 with Cloudflare's Just a moment… interstitial — not a session-specific denial, the bare root. The same page comes back for session and API paths. We verified with controls that this is not our egress or our proxy: our own hosts return normally through the same client, and a blocked host fails differently (connection refused rather than a challenge page). One path is exempt — claude.ai/code/artifact/<uuid> returns 200 — but only the shell; its data endpoint /api/frame/<uuid> is challenged like everything else.

So we are not reporting a permissions error. We are saying we cannot reach a surface to find out whether one exists, and a browser session appears to be the only client that can.

What we are not asking for: a way around the bot protection. We explicitly declined to build a relay holding browser-born credentials, and we are not looking for an undocumented endpoint. If the answer is "no supported programmatic read exists", that is a useful answer and we will design around it.

---

Notes for sending

• Who: the account owner. A session cannot speak for the account, and question 1 is about what this account is served.
• Where the answer goes: back onto this issue as a comment with a link. #338 step 15 and #342 both discharge against it.
• What deliberately is not in it: the org's internal issue numbers, our repo names, the pathbase door, and anything about our claim machinery. None of it helps the reader and some of it is private.
• Tone check: it asks two answerable questions and states what we already tried, including the control that rules out our own infrastructure. It does not assert a bug.

---

Generated by Claude Code

[bdelanghe]

Third independent measurement of the classifier's silent denial

This issue is the vendor ask about the classifier naming no route. Two more data points arrived tonight, from positions the original write-up did not cover:

1. This session, twice, writing the narrow allowlist for Act on the P2–P6 findings: make the channel out real, and the verbs findable #343 fix 1b — refused on Bash and again on Edit, same content, no route named. Written only after the maintainer directed it explicitly.
2. A subagent, tonight, doing nothing but reading: echo $CLAUDE_CODE_SESSION_ID and an explicit read_session were each denied once, then permitted on a single retry with a trivially different spelling (printenv; the same read with offset added).

With P4's original curl denial that is three independent positions — a bare checkout-less session, a full session with repos attached, and an in-process child — and the second case is the sharper evidence, because nothing about the retry changed the capability being exercised. The same read, spelled differently, was allowed. A gate that admits a call on the second spelling is not expressing a policy the caller can learn; it is noise the caller routes around by accident.

That is the argument for the ask in one line: the denial is not reproducible from the caller's side, so the caller cannot tell a policy from a coin flip. Naming the route would make the first case actionable and the second case obviously a bug.

Recorded in the read matrix (#372) and the posture matrix (#337). Still needs your account to send.

---

Generated by Claude Code