Context window balloons at fresh-session start (~40-70K baseline tokens) and full-file re-injection on every auto-compact

**Environment:** Claude Code 2.1.259 (macOS Darwin 24.5.0, arm64), VS Code extension 2.1.259, Sonnet 5 (Pro plan)

**Summary:** Two related but distinct issues, both confirmed with direct evidence from session transcript files (`~/.claude/projects/*/*.jsonl`), not speculation.

**Issue A — Fresh-session-start baseline (~20-35% of window before any real work):**
Measured the very first assistant turn's `usage` field across 10 independent fresh sessions (5 in one project, 5 in another): totals ranged 40,613-43,344 tokens in one project and 44,252-69,534 in another. Notably, `cache_read_input_tokens` was **identically 7,298** across 5 separate sessions in the same project — a fixed, cached harness-level cost. No `type:"file"` attachments were present at session start in any sample, ruling out "recently read files" as the cause. Tried 4 fixes across earlier sessions (disabling zero-usage plugins, narrowing global MCP server scope, isolating a specific plugin's SessionStart hook, trimming personal `CLAUDE.md`) — none moved this baseline more than a few percent. Best available explanation (by elimination, not direct measurement): cumulative cost of per-session skill-catalog/agent-type-listing/deferred-tool-name-list/MCP-instruction injection that Claude Code sends on every session start regardless of plugin count.

**Issue B — Full-file re-injection on every auto-compact:**
Scanned all 92 session files in one project for `isCompactSummary` markers: found 42 real auto-compact events. In each, following the compact summary, Claude Code re-attaches: (1) the compact summary itself, (2) a subset of files recently touched via `Read` as **full content** (`attachment.type:"file"`, averaging ~7.8KB per event) rather than the lightweight `compact_file_reference` given to other touched files, (3) `deferred_tools_delta`, `agent_listing_delta`, `mcp_instructions_delta` (present in 41/42 events), (4) SessionStart:compact hook output including a plugin's full skill text. This appears to be **not proportional to actual new content** — it's a re-send of largely-unchanged state on every single compact, which compounds over long sessions. Cross-project check: auto-compact never fired in shorter-lived project sessions (longest observed: 3,692 lines) — only in the one project with marathon 30K+ line sessions — consistent with the ~83.5% documented auto-compact threshold, but the *reinjection cost itself* at each compact appears avoidable/reducible.

**Ask:**
1. Is there a way to make compact's per-file full/reference decision configurable, or default more conservatively to references?
2. Can agent-listing/deferred-tools/MCP-instruction blocks be sent as true deltas (only what changed) instead of full resends at every compact?
3. Is the ~40-70K fixed session-start cost expected to scale with plugin/skill count, and is there a lighter-weight catalog-reference mode instead of full injection?

Start with the session transcript files at ~/.claude/projects/*/*.jsonl and reproduce fresh-session and auto-compact usage, checking usage, isCompactSummary, attachment.type, compact_file_reference, and the delta blocks. Done means determining whether full-file reinjection and session-start catalog, tool, and MCP costs can be made configurable or reduced to true deltas, with evidence from comparable transcripts.

Written by the indexing model from the issue text.