query({resume}) silently drops tool_use/tool_result sequences from earlier turns when session JSONL grows large

# DRAFT — upstream SDK issue

**Target repo:** `anthropics/claude-agent-sdk-typescript`

**Title:** `query({resume}) silently drops tool_use/tool_result sequences from earlier turns when session JSONL grows large`

---

## Summary

`query()` with `resume: sessionId` reconstructs conversation from the JSONL on disk before sending to the API. On long sessions with frequent tool use, the reconstruction appears to drop tool_use/tool_result sequences from earlier turns while retaining user/assistant text. From the agent's perspective this looks like "I can remember what was said but not what I did." Concrete result: agents duplicate side-effecting actions (file uploads, external API writes) because their prior successful actions are invisible to them.

## Observed

Single-session JSONL across container reboots. Session grew to ~1.8 MB (~450k raw tokens of content) over 17 hours of normal use.

Per-boot `cache_creation_input_tokens` for the first assistant response after each user message (cache_read_input_tokens ≈ 14k in every case — baseline system-prompt cache, indicating a fresh container boot):

| Boot | File size at boot | cache_create |
|---|---|---|
| #1 | ~200 KB | 12,168 |
| #2 | ~800 KB | 47,445 |
| #3 | ~1.1 MB | 64,700 |
| #4 | ~1.3 MB | 65,171 |
| #5 | ~1.6 MB | 76,368 |
| #6 (controlled test) | 1.8 MB | 76,577 |
| controlled test, trimmed | 306 KB | 46,571 |
| controlled test, pristine SDK-native | 647 KB | 57,858 |

Cache_create plateaus well below the model's context window (200k). It scales sub-linearly with file size. The SDK's `Ao6` parent-chain walker (in the bundled `cli.js`) does NOT filter by entry type — it traverses progress, user, assistant, sidechain uniformly — so the reduction happens downstream of the walk, in reconstruction filters (`MS1` / `mTq` progress filters, `gGq` tool-result pairing repair, or a token-budget clamp I could not pinpoint in the minified bundle).

## Reproduction concrete

At boot #3, an agent responding to a user message that requested "do X and log to storage Y":

1. Had in its context the user's prior message ("log thing, upload artifact")
2. Had in its context its own prior text response acknowledging those actions
3. **Did NOT have in its context** the tool_use entries for the sheet append or the external source-add that implemented those actions in the earlier turn
4. Decided, correctly per its skill instructions, that because there was no evidence of the external upload in its visible history, it should upload now
5. Dispatched a second source-add with identical parameters → external backend created a duplicate record

Pattern is consistent across subsequent boots in the same session. The user/assistant TEXT of prior turns survives; the tool_use/tool_result sequences from those same turns do not.

## Impact

Any multi-turn agent that uses tools to mutate external state (databases, cloud storage, notebooks, APIs without idempotency keys) will duplicate actions when:

1. A new container / new process / any other mechanism triggers a session resume, AND
2. The resumed session is long enough that reconstruction trims earlier tool sequences.

Agents with robust read-before-write guards at every write site survive this. Agents without them don't. In one observed session across a single day we ended up with: duplicate notebook source, duplicate cloud-storage folder, duplicate file upload.

## Not the same as #287

This bug has no dangling parent in the walked chain — `Ao6` reaches back 17 hours of history through progress entries without hitting a break. Workaround from #287 (parent-chain linearization) does not help here. This is a distinct downstream pruning behavior.

## Expected

One of:

1. Reconstruction preserves tool_use/tool_result pairs as first-class conversation content, same as user/assistant text — they are what the agent relies on to know what it has done.
2. Reconstruction provides a documented, configurable budget for resumed conversation reconstruction, so long-session agents can opt into a higher ceiling.
3. If pruning is intentional for token-budget reasons, the SDK exposes an API to inject a "summary of prior work" into reconstructed context so the agent at minimum knows prior actions happened.

## Environment

- `@anthropic-ai/claude-agent-sdk` version: bundled — reproducible on `sdk.mjs` size 404900 bytes
- Node.js v22
- Provider: Anthropic (Opus 4.6 via OAuth)
- `autoCompactEnabled` default on (irrelevant here — observed context is ~76k of the 200k window, well below the auto-compact threshold)

---

This issue was written by Claude Code (model: claude-opus-4-7).