1. src/agents/session-transcript-repair.ts, line 261-297 (link)

   Snake_case blocks bypass sanitization and are silently lost in mixed-type messages

   The inner type guard (lines 262–266) was not updated alongside isRawToolCallBlock, so it still only matches the three camelCase variants. This creates two concrete problems:

   1. sessions_spawn attachment redaction is skipped for tool_use blocks.
   sanitizeToolCallBlock — which strips sensitive inline attachment content — is only reached when the inner if (camelCase) branch is entered. A sessions_spawn call that arrives with Anthropic's native tool_use type will pass isRawToolCallBlock, survive the drop check (it has input), but then fall through the inner guard without ever calling sanitizeToolCallBlock. The raw attachment content is persisted to session history un-redacted.

   2. Valid snake_case blocks are silently dropped when any sibling camelCase block has been mutated.
   If messageChanged becomes true for another block in the same content array (e.g. a camelCase toolUse whose sessions_spawn attachments were redacted, or a padded name that was trimmed), the loop exits and the code reaches out.push({ ...msg, content: nextContent }) — using nextContent, which never received the snake_case block. The block disappears from the session without being counted as dropped.

   The reason the two new tests pass despite this gap: in a message containing only snake_case blocks no mutation is triggered, so messageChanged stays false and droppedInMessage stays 0, falling through to out.push(msg) which preserves the untouched original msg. This is accidentally correct for that narrow case but masks the two failure modes above.

   The fix is to add the snake_case types to the inner guard so they receive the same sanitization path:

   // src/agents/session-transcript-repair.ts – lines 262-266
         if (
           (block as { type?: unknown }).type === "toolCall" ||
           (block as { type?: unknown }).type === "toolUse" ||
           (block as { type?: unknown }).type === "functionCall" ||
           (block as { type?: unknown }).type === "tool_call" ||
           (block as { type?: unknown }).type === "tool_use" ||
           (block as { type?: unknown }).type === "function_call"
         ) {

   A companion test covering sessions_spawn with type tool_use and attachments would confirm the redaction path is now reached for snake_case blocks.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/agents/session-transcript-repair.ts
   Line: 261-297
   
   Comment:
   **Snake_case blocks bypass sanitization and are silently lost in mixed-type messages**
   
   The inner type guard (lines 262–266) was not updated alongside `isRawToolCallBlock`, so it still only matches the three camelCase variants. This creates two concrete problems:
   
   **1. `sessions_spawn` attachment redaction is skipped for `tool_use` blocks.**
   `sanitizeToolCallBlock` — which strips sensitive inline attachment content — is only reached when the inner `if (camelCase)` branch is entered. A `sessions_spawn` call that arrives with Anthropic's native `tool_use` type will pass `isRawToolCallBlock`, survive the drop check (it has `input`), but then fall through the inner guard without ever calling `sanitizeToolCallBlock`. The raw attachment content is persisted to session history un-redacted.
   
   **2. Valid snake_case blocks are silently dropped when any sibling camelCase block has been mutated.**
   If `messageChanged` becomes `true` for another block in the same content array (e.g. a camelCase `toolUse` whose `sessions_spawn` attachments were redacted, or a padded name that was trimmed), the loop exits and the code reaches `out.push({ ...msg, content: nextContent })` — using `nextContent`, which never received the snake_case block. The block disappears from the session without being counted as dropped.
   
   The reason the two new tests pass despite this gap: in a message containing _only_ snake_case blocks no mutation is triggered, so `messageChanged` stays `false` and `droppedInMessage` stays `0`, falling through to `out.push(msg)` which preserves the untouched original `msg`. This is accidentally correct for that narrow case but masks the two failure modes above.
   
   The fix is to add the snake_case types to the inner guard so they receive the same sanitization path:
   
   ```typescript
   // src/agents/session-transcript-repair.ts – lines 262-266
         if (
           (block as { type?: unknown }).type === "toolCall" ||
           (block as { type?: unknown }).type === "toolUse" ||
           (block as { type?: unknown }).type === "functionCall" ||
           (block as { type?: unknown }).type === "tool_call" ||
           (block as { type?: unknown }).type === "tool_use" ||
           (block as { type?: unknown }).type === "function_call"
         ) {
   ```
   
   A companion test covering `sessions_spawn` with type `tool_use` and attachments would confirm the redaction path is now reached for snake_case blocks.
   
   How can I resolve this? If you propose a fix, please make it concise.

Best possible solution:

Land this PR, or an equivalent main-branch fix, after mergeability is restored and exact-head validation passes; keep linked #48915 open until the implementation merges.

Do we have a high-confidence way to reproduce the issue?

Yes, from source inspection. A persisted assistant block like { type: "tool_use", id: "call_1", name: "read" } missing input and arguments is ignored by current main's camelCase-only detector, so it bypasses the documented malformed-tool-call drop path before replay.

Is this the best way to solve the issue?

Yes. The PR applies the same narrow type-set expansion across detection, rebuild/redaction, result-pairing extraction, ID rewriting, tests, and changelog without adding a provider-specific migration or new policy knob.

Acceptance criteria:

• pnpm test -- src/agents/session-transcript-repair.test.ts src/agents/tool-call-id.test.ts
• pnpm check:changed

What I checked:

• Current main detector gap: isRawToolCallBlock() still recognizes only toolCall, toolUse, and functionCall, so a persisted tool_use block is not selected for malformed tool-call repair on main. (src/agents/session-transcript-repair.ts:32, 103cdd9d96f8)
• Current main rebuild/redaction gap: The rebuild path inside repairToolCallInputs() is also camelCase-only; this is the path that preserves valid blocks and redacts sessions_spawn attachment payloads. (src/agents/session-transcript-repair.ts:352, 103cdd9d96f8)
• Current main ID helper gap: TOOL_CALL_TYPES and rewriteAssistantToolCallIds() are camelCase-only on main, so snake_case assistant calls are missed by extraction and ID rewriting. (src/agents/tool-call-id.ts:14, 103cdd9d96f8)
• Replay pipeline uses affected helpers: sanitizeSessionHistory() applies sanitizeToolCallInputs(), result-pairing repair, and optional tool-call ID sanitization before provider replay, placing the missed block types on the model replay path. (src/agents/pi-embedded-runner/replay-history.ts:652, 103cdd9d96f8)
• Documented expected behavior: Transcript hygiene docs say assistant tool-call blocks missing both input and arguments are dropped before model context is built. Public docs: docs/reference/transcript-hygiene.md. (docs/reference/transcript-hygiene.md:81, 103cdd9d96f8)
• Anthropic transport shape: The Anthropic transport emits assistant tool calls to the provider as type: "tool_use" with input, matching the snake_case shape reported in linked [Bug]: isRawToolCallBlock misses snake_case tool call types (tool_use, tool_call), causing corrupted session history errors with Anthropic #48915. (src/agents/anthropic-transport-stream.ts:374, 103cdd9d96f8)

Likely related people:

• steipete: GitHub commit history shows repeated recent work in transcript repair, tool-call ID helpers, and replay-history paths, including shared tool-call transcript helpers and strict provider replay fixes. (role: recent maintainer / routing owner; confidence: high; commits: 848f154f3eaa, ea1e933b29a2, 7f6452897e25; files: src/agents/session-transcript-repair.ts, src/agents/tool-call-id.ts, src/agents/pi-embedded-runner/replay-history.ts)
• vincentkoc: The PR timeline says vincentkoc pushed the current narrow repair branch, and recent history shows adjacent work on sessions_spawn redaction, OpenAI replay IDs, and transcript hygiene docs. (role: PR branch maintainer / adjacent owner; confidence: medium; commits: 4a1eeab0f107, efc3a52947e9, a09e228e3e8e; files: src/agents/session-transcript-repair.ts, src/agents/tool-call-id.ts, docs/reference/transcript-hygiene.md)
• jalehman: Recent merged history includes the malformed replay tool-call sanitizer work on the same transcript-repair surface, which is directly adjacent to this PR's bug path. (role: adjacent feature-history owner; confidence: medium; commits: c3972982b5d4; files: src/agents/session-transcript-repair.ts)

Remaining risk / open question:

• The provided PR context reports mergeable: false, so the branch may need rebase or conflict handling before exact-head validation.
• I did not run tests in this read-only review because pnpm is unavailable in the checkout; validation should still run on the exact PR head before merge.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 103cdd9d96f8.