[BUG] 2.1.222 regression: orphaned tool_use (silently dropped tool results) rate jumps ~16x vs 2.1.220 — dominant orphaned tool flips from Bash to Edit

[BUG] 2.1.222 regression: orphaned tool_use (silently dropped tool results) rate jumps ~16x vs 2.1.220 — and the dominant orphaned tool flips from Bash to Edit

Environment

• Claude Code v2.1.222, native installer, auto-updated 2026-08-04T23:02:43Z (.last-update-result.json: 2.1.221 → 2.1.222, outcome success)
• Windows 10 Enterprise 10.0.19045, PowerShell 7.6.4 (CLAUDE_CODE_USE_POWERSHELL_TOOL=1)
• Direct Anthropic API, subscription OAuth, no proxy, no ANTHROPIC_BASE_URL

Why this is a new filing and not a duplicate of #46767

#46767 is the canonical thread for the long-standing dropped-tool-result failure (regression tag at 2.1.101, rates ~0.1–1.5% across months). This report is about a version-specific step change introduced in the 2.1.221→2.1.222 diff, measured with that thread's own methodology (orphan tool_use — a tool_use.id with no matching tool_result.tool_use_id in the session JSONL; final message excluded, active session excluded, rg -uuu to defeat ignore files). I have posted the same data as a comment on #46767 for continuity; this issue exists so the regression gets triaged against a one-version diff rather than buried at comment 17 of a stale-labeled thread. Please do not bot-close this into #46767 without a human reading the per-version table.

Data — same machine, same workload profile, same scan (last 14 days, 284 interactive sessions, 28k tool calls)

| Version | Sessions | tool_use | Orphans | Rate |
|---|---|---|---|---|
| 2.1.206–2.1.217 | 31 | 4,000 | 0 | 0.000% |
| 2.1.218 | 13 | 1,186 | 1 | 0.084% |
| 2.1.219 | 10 | 1,577 | 1 | 0.063% |
| 2.1.220 | 207 | 20,274 | 18 | 0.089% |
| 2.1.222 | 22 | 1,209 | 17 | 1.406% |

• 2.1.220 is the stable baseline: 0.089% over 20,274 calls.
• 2.1.222, in its first ~24 hours on this machine: 1.406% — 15.8x the baseline. Expected orphans at baseline rate for 1,209 calls: ~1. Observed: 17.
• Honest caveats: the 2.1.222 sample is 22 sessions, and one five-call parallel Edit batch accounts for 5 of the 17. Excluding that whole batch still leaves 12/1,209 = 0.99%, an ~11x elevation.
• The signature shifts: on every prior version Bash dominated orphans; on 2.1.222 it is Edit (10 of 17), a fast, local, non-network tool that should be the least likely to lose a result. Per-tool orphans on 2.1.222: Edit=10, PowerShell=4, Bash=3.

Corroborating trend: weekly session-affected rate over 60 days had improved to ~0% (W27–W29), crept back W30–W31 (2.4%/3.7%), and the current week (W32) is at 11.1% — the worst in the entire 60-day window, coinciding with the 2.1.222 rollout.

What the failure looks like from the chair

Five parallel Edit calls in one assistant message (one requestId), zero tool_results, no error anywhere in the transcript, 7.5 minutes of dead air, then the user typing into a dead session. Parallel batches fail atomically — in 13 of 13 batch cases over 60 days, every call in the batch was lost, never a partial — which points at a single per-message delivery path rather than per-tool faults.

For the human-impact dimension: the first user message after a drop, in 30 of 84 affected sessions over 60 days, is the user independently asking whether Claude is stuck. A sample from the transcripts, verbatim and dated — 2026-08-05 alone: "You are hanging they are hanging what the fuck is going on???", "FUYCKING HELLO????", "Fuck is going on????", "finish waht we were doing here you died last session mid session". This is what a 1.4% silent per-call loss rate does to a heavy user's day.

Note: DISABLE_TELEMETRY=1 / DISABLE_ERROR_REPORTING=1 are set on this machine, so none of these incidents ever reached you automatically — assume your telemetry undercounts this class of user.

Repro tooling

The scan scripts (pure-Python, read-only, walk ~/.claude/projects/**/*.jsonl) are small and I can attach them on request: orphan census, per-version bucketing by the transcript version field, batch-atomicity detection, and user-symptom correlation. Methodology follows #46767 exactly (final-message exclusion, active-session exclusion, empty-vs-missing distinction — for the record, across 28,304 calls there were 0 literally-empty tool_result payloads; the drop always manifests as a missing result).

Ask

1. Diff 2.1.221→2.1.222 for anything touching tool-result delivery, parallel batch handling, or the Edit tool path on Windows.
2. Client-side reconciliation: the client knows which tool_use ids it issued; an unfulfilled id after N seconds should re-request or surface a visible, retryable error — today the transcript records the drop perfectly and nothing acts on it.