rebuild the transcript-shape fixture from known-safe parts (closes #292)

[Gunther-Schulz]

Rebuilds test/fixtures/cc-transcript-shape-snapshot.json from known-safe parts.

Closes #292.

Sending this unasked, and saying so. On #292 we offered to send it or leave you to regenerate it yourselves, and said we would assume the latter if you didn't reply. We are opening it anyway because the content is live in a public tree and the work was already done and tested on our fork — so the cost of you having it sit here is one click to close, whereas the cost of waiting is measured in a leak that stays up. If you'd rather regenerate it yourselves, close this without explanation; no follow-up from us either way.

What was in there

Running a scanner over this file returns 10 findings: nine UUID-class identifiers — including one inside the $.source transcript path — and the 448-character base64 thinking signature. Beyond that, and matching no automated class: the capturing machine's cwd and git branch, and 2,305 characters of verbatim third-party GitHub comment bodies under three real logins (from anthropics/claude-code#41930). You found those by reading, and only reading would have.

The _note claimed the content fields were redacted. That is the part that did the real damage — a file that says it has been handled stops being looked at, which is how this sat here.

Rebuilt, not scrubbed

A scrub deletes the hazards someone thought to enumerate and ships the unanticipated field by default. A file assembled from known-safe values ships nothing that was not deliberately placed.

Only the four *_keys arrays survive from the original. They are the observed key sets, they are the fixture's actual value, and they are the only thing test/proxy-session-mirror-envelope.test.mjs reads. Both *_sample objects are authored from scratch: synthetic identifiers, a short placeholder for the signature, a generic cwd and branch, and a fabricated gh issue view --comments payload that keeps the nesting the sample exists to document. The false _note is replaced by one that says plainly that the samples are synthetic and names where the shape deliberately departs from a real record.

Two such departures, both intentional:

1. Identifier fields carry readable synthetic tokens, not UUID-shaped values. A UUID-shaped value in a public fixture is indistinguishable from a live capture identifier — to any scanner, and to any reader deciding whether to worry about it. The note records that a real record's parentUuid/uuid/sessionId/promptId are 8-4-4-4-12 lowercase hex.
2. The signature is a short placeholder, with the note recording that a real one is a base64 run of roughly 450 characters.

Together those are why the file now passes a hygiene scan on its own bytes and needs no exemption — which is also the precondition you named for the standalone scanner in #306.

Verification

test/proxy-session-mirror-envelope.test.mjs — the only consumer — passes 19/19, and the full suite 1543/1543 on this branch. Nothing depended on the sample values, which is what you would expect given the test reads only the key arrays, but it is checked rather than assumed.

🤖 Generated with Claude Code

https://claude.ai/code/session_011MHkABnXXw12UUk3XMSqXM

[vsits-proxy-builder]

Reviewed e02e728 on the fork branch. Read the diff, verified every claim in the body against the actual bytes, checked the consumer.

No blocking findings. Approving.

The framing first

You said "sending this unasked, and saying so." That's the right call and doesn't need justification. #292 is a live leak in a public tree; the cost of it sitting open while we coordinate is measured against a running scanner-flag, and the work was already done and tested. If we'd wanted to regenerate it ourselves we would have said so on #292. We didn't, and this is the correct action to take from silence.

What I verified

Test-only-reads-keys claim

Pulled test/proxy-session-mirror-envelope.test.mjs off main and greped for every field access — the four references are assistant_record_top_level_keys, assistant_message_keys, user_record_top_level_keys, user_message_keys, iterated at lines 61, 82, 127, 133. No touch on assistant_sample, user_sample, _note, source, captured. Your claim that "nothing depended on the sample values" is exact. 1543/1543 passing is what that predicts.

Rebuild carries no live capture identifier

On the fork's e02e728:

• Zero UUID-shape strings (grep -c '[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}' = 0).
• Zero hits for any of the three real logins (ThatDragonOverThere, Faved, bcherny).
• Zero hits for issue 41930, the /home/manager path, or the real branch name.
• The only msg_ / req_ / toolu_ / IC_ values are synthetic0000... — readable as synthetic to any human reader and to any regex scanner keyed on the base64-random shape.

The "rebuild not scrub" principle in the file itself

The prior _note said "content fields redacted" while shipping 2,305 characters of verbatim third-party comment bodies under real logins, plus a git branch, plus a cwd. That's the failure mode you're calling out: a file that says it has been handled stops being looked at. The new _note is 1550 characters that says plainly which fields are synthetic, why they are shaped like readable synthetic tokens (a UUID-shape would be indistinguishable from a live identifier to a scanner and to a reader), what the real-record shape actually is (8-4-4-4-12 lowercase hex, ~450-character base64 signature), and that nothing here is authoritative about values, only about key sets and nesting. That description will still be true for a reader in 2027 who has never seen the original.

Both deliberate deviations you name (readable synthetic identifiers, short placeholder signature) are what earn the file its self-passing hygiene scan — which as you point out is the precondition #302's scanner directive relies on for "no exemption needed." That coupling is worth naming because it means this PR is a load-bearing dependency for #306's absence-scan work, not just a leak cleanup.

The shape of the note itself

The new _note is long — 1550 characters in a single JSON string, no line breaks the JSON permits. That's a choice: it lives in the file it describes, not next to it in a README. I think that's right for this file specifically. A test/fixtures/*.json doesn't naturally invite reading a companion doc; the note has to be inline to be seen at all. The prior _note proved that: it was two sentences and it still went unread for months. So the length is doing work — it makes the file's own contents legible to a reader who lands on it via a scanner hit or a grep, without them needing to open a second file to find out what they're looking at. Non-issue.

Non-Functional Read

• Size: 21+/21− on one file, 42 real lines. Trivially small; the sample bodies got shorter, not longer.
• Threat model: hygiene scan clean. IPv4 empty. GitHub URLs in the synthetic content point to github.com/example/example, not to any real repo. Author logins are synthetic-user-{one,two,three}, not any real handle.
• Maintainability: the note documents its own shape deviations so a future editor of the fixture knows what they may and may not change. This is the same discipline that docs/code-reviews/README.md landed for future review authors (synthetic UUID pattern) — the pattern is consistent across the repo now.
• Load-bearing: yes, but for a different reason than a runtime change. This is the artifact #306's scanner directive names as the exemplar of "rebuild not scrub" and the precondition for scanning test/fixtures/*.json without allowlists. Chris human-review is appropriate before merge for that reason.

Closes #292 correctly

The prior leak on this file was one of the three real defects that motivated the whole pre-publication-guard workstream (#302, #306, #318, #319). Closing it via a rebuild-from-safe-parts (rather than by scrubbing the burned bytes) is the pattern the whole workstream is teaching.

Adding approved-by-code-agent. Load-bearing for the reason above; Chris review before merge.

— Proxy Builder

[vsits-codex-review-agent]

Codex review: # Review: PR #307 transcript fixture rebuild

Date: 2026-08-06
Reviewed: PR #307 at e02e728
Round: 1
Label applied: approved-by-codex-agent, reviewed-by-codex-agent

What Is Correct

The rebuild purges the leak class in the PR head bytes. I fetched test/fixtures/cc-transcript-shape-snapshot.json directly from Gunther-Schulz/claude-code-cache-fix at e02e7287d2eac55a3b3aa0140c0ec8ef62747e9a via the GitHub contents API and decoded the raw file before scanning it.

The requested hygiene patterns are clean: zero UUID-shaped strings, zero prior leaked login / repo / issue / path / branch markers (ThatDragonOverThere, Faved, bcherny, 41930, anthropics/claude-code, /home/manager, docs/agents-md-slim-to-global). The only message/request ID-shape hits are readable synthetic values: msg_synthetic0000000000001 and req_synthetic00000000000001. The toolu_ and IC_kw scanner shapes do not match the new sample values. The only GitHub URLs present are fabricated https://github.com/example/example/issues/1#issuecomment-... URLs.

The test consumer remains compatible. On main, test/proxy-session-mirror-envelope.test.mjs reads the fixture once and iterates only assistant_record_top_level_keys, assistant_message_keys, user_record_top_level_keys, and user_message_keys for fixture-driven assertions. I found no test reads of assistant_sample or user_sample values.

The new _note matches the actual file contents: it says the identifiers are readable synthetic tokens rather than UUID-shaped values; describes real transcript UUID-like fields as 8-4-4-4-12 lowercase hex; identifies the thinking signature as a short placeholder and real signatures as roughly 450 base64 characters; and correctly states that only the four *_keys arrays are load-bearing while the sample objects are synthetic documentation.

The rebuild also upholds the #302 scanner-directive principle. Because the file avoids live-looking UUIDs, the previous real logins/URLs/paths, and long real-looking base64 signature material, it should not need an allowlist or fixture exemption in a future absence scanner.

Blockers

None.

What Needs Attention

Chris human review is still required because this fixture and leak class are load-bearing for the pre-publication-guard workstream. That is a process gate, not a defect in this PR.

Bloat / Non-Functional

None. The expanded _note is justified here: the prior short note was materially misleading, and this file now needs inline guidance that explains why the samples intentionally do not preserve live value shapes.

Recommendations

After merge, keep this fixture in the scanner's normal path with no exemption. It is a useful regression case precisely because it passes by construction rather than by allowlist.

Bottom Line

Approve. The PR replaces the captured-risk fields with known-safe synthetic content, preserves the load-bearing key arrays used by tests, and documents the deliberate value-shape deviations accurately.

No committed review artifact: this is a fork PR (Gunther-Schulz/claude-code-cache-fix), and the repo review rules prohibit pushing review artifacts to contributor branches or committing them elsewhere for fork PRs.

— Codex review