[BUG] Tool results silently dropped with "missing due to internal error" across all tools on Windows (regression in 2.1.101)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/43866
2. https://github.com/anthropics/claude-code/issues/46032
3. https://github.com/anthropics/claude-code/issues/39830

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Thanks bot — going through the three candidates.

#43866 — not a duplicate. That issue is scoped specifically to the Skill
tool ("Skill tool call returns..."). Our report covers Bash, Glob, Read,
Write, and WebFetch, with no Skill involvement at all. Different scope.

#39830 — not a duplicate. That issue is about parallel Agent calls
losing tool_results in concurrent execution. Our failures happen on
sequential, single-agent turns with no parallelism and no Agent tool use.
Different trigger.

#46032 — closest candidate, but meaningful differences. Flagging for
triage to judge. Both reports describe tool results failing to reach
the model across multiple tools, and both name a recent version as a
regression. However:

1. Different regression points. #46032 reports 2.1.98 broken /

2.1.92 working. I scanned ~163 session transcripts on this machine
across 2026-04-04 → 2026-04-11, versions 2.1.84/85/86/92/101, and
the "missing due to internal error" wrapper string appears in
exactly 2 session files, BOTH on 2026-04-11 — the day 2.1.101
landed. Earlier versions show no occurrences. If 2.1.98 were
broken in the same way on my platform, I would expect to see it in
transcripts from 04-08 to 04-10. I don't.

1. Different failure signature. #46032 reports empty <tools></tools>

output — i.e., the wrapper delivers nothing at all. My report is the
opposite: the wrapper delivers a specific sentinel string,
[Tool result missing due to internal error], that the model
receives as if it were tool output. These could be two failure modes
of the same wrapper bug, or two different bugs. I can't tell from
the outside.

1. Different platforms. #46032 is macOS / Terminal.app / zsh. Mine

is Windows 11 native installer / Git Bash. That doesn't rule out a
shared root cause in the platform-agnostic wrapper layer, but it
does mean reproduction environments don't overlap.

1. Unique diagnostic in mine. During the diagnosis session itself,

WebFetch to https://registry.npmjs.org/@anthropic-ai/claude-code
returned the sentinel error — a plain HTTPS fetch with no subprocess,
no filesystem, no Windows-specific shell interaction. This rules out
"Windows command-shape" or "subprocess-wrapping" as the root cause on
my side and points at the tool-result delivery layer itself. #46032
doesn't have this data point.

If Anthropic triage determines these share a root cause, happy to
close this as a duplicate and 👍 #46032 with my extra diagnostic info
added as a comment over there. But I'd rather leave the judgment to
whoever is familiar with the wrapper internals than guess. 👎 on the
bot to prevent auto-closure in the meantime.

Update — 8 days of additional Windows evidence (2026-04-11 → 2026-04-19)

Continuing to hit this on 2.1.98 — the downgrade reduces severity but does not fix the underlying bug. Sharing structured data in case it helps triage.

Sentinel occurrences in session transcripts

Scanned all session JSONL files under ~/.claude/sessions/ for the string Tool result missing due to internal error since 2026-04-11.

64 occurrences across 12 session files over 9 days.

| Date | Hits | Notes |
|------|------|-------|
| 2026-04-11 | 27 | Last day on 2.1.101 (downgraded that evening) |
| 2026-04-12 | 14 | First full day on 2.1.98 |
| 2026-04-16 | 7 | |
| 2026-04-17 | 2 | |
| 2026-04-18 | 4 | |
| 2026-04-19 | 10 | Includes a live reproduction during a debugging session |

Tools affected

| Tool | Hits |
|------|------|
| Read | 14 |
| Edit | 11 |
| Grep | 6 |
| Bash | 5 |
| Agent | 4 |
| Write | 4 |
| WebFetch | 4 |
| Glob | 2 |
| MCP tool call | 1 |

Every tool type in regular use is represented. This rules out subprocess-shape, Windows command parsing, or any tool-specific implementation as the root cause.

Parallel batches are the dominant trigger

~62% of failures (≈40 of 64) occur in clusters of 2-4 consecutive sentinel returns within the same tool-result batch. Examples from one session on 2026-04-11:

• 3× Edit calls failing simultaneously
• 3× WebFetch calls failing simultaneously
• 4× Edit calls failing simultaneously

Single-call retries of the exact same operations succeed immediately. The trigger is the batch, not the individual call shape.

Sessions hang often enough to require manual recovery

The host runs Claude Code as an always-on --remote-control service. Restart history from the launcher log:

• 16 total restarts in the period
• 8 are the scheduled daily restart (~04:31)
• 8 are unscheduled restarts I triggered manually (some at the terminal, some remotely via MCP) to recover hung sessions when the Escape-interrupt trick wasn't usable — either because I was remote, or because the queued-message workflow didn't recover the session

That's roughly one forced kill-and-relaunch per day on average over the period. Each one is a session that hung in a way the in-process recovery couldn't address.

Recovery diagnostic — the Claude process is not deadlocked

Manual recovery workflow that consistently works at the terminal:

1. Type any message into the prompt (queues it)
2. Press Escape (interrupts the hung tool call)
3. Claude flushes the queued message, the session resumes normally

The fact that keyboard input is still being read and Escape successfully interrupts the in-flight tool call means the Claude Code process itself is responsive — only the tool-result delivery channel is broken. This narrows the bug to the wrapper layer that hands tool results back to the model.

Infrastructure context (for ruling out)

• WhitCortex agent and MCP servers stay healthy through every Claude Code hang — no MCP disconnects logged
• No crash dumps produced
• 100% first-attempt success on relaunches — the launcher is not the problem
• Failure is silent from outside the Claude Code process

Happy to provide raw session file paths or specific timestamp ranges if useful for repro.

Cross-platform reproduction — same fault on Linux 2.1.114

Following up on the Windows evidence above. I reproduced the same fault pattern on a separate machine running Linux, and re-scanned the Windows data with a more rigorous methodology. This confirms the bug is not Windows-specific and not bound to the 2.1.98–2.1.101 regression window.

Methodology refinement

The literal string Tool result missing due to internal error is not reliably persisted in session JSONL — Claude Code injects it at render time. The persistent on-disk signature of the fault is an orphan tool_use: a tool_use block whose id has no matching tool_use_id in any subsequent tool_result in the same session. This is the canonical signal and is what’s counted below for both platforms.

Note: my earlier comment in this thread used a string scan and slightly over-counted. The orphan-tool_use methodology supersedes it.

In-flight orphans (the very last tool_use in an active session, which may still resolve) are excluded. Tool calls that legitimately kill the session (e.g., a restart-Claude-Code MCP tool) are also expected orphans and excluded.

Cross-platform comparison

| Metric | Windows | Linux (Steam Deck) |
|---|---|---|
| Claude Code version | 2.1.98 | 2.1.114 |
| Kernel / OS | Windows 11 native installer | Linux 6.11.11 (SteamOS) |
| Deployment | Always-on --remote-control service | Interactive --remote-control session on local codebase |
| Period | 2026-04-11 → 2026-04-20 (9 days UTC) | 2026-04-19 (1 day) |
| Sessions scanned | 25 | 3 |
| tool_use events | 4,420 | 418 |
| Orphans | 51 | 7 |
| Orphan rate | 1.15% | 1.67% |
| Tools affected | Bash 34, Agent 7, Write 3, Grep 2, Glob 1, WebFetch 1, Edit 1, MCP 1, Read 1 | Bash 7 |
| Parallel-batch clustered (≤5 lines apart) | 22 of 51 (43%) | 2 of 7 (29%) |

Windows orphans by date

| Date (UTC) | Hits |
|---|---|
| 2026-04-11 | 10 |
| 2026-04-12 | 6 |
| 2026-04-13 | 1 |
| 2026-04-14 | 8 |
| 2026-04-15 | 3 |
| 2026-04-16 | 9 |
| 2026-04-17 | 1 |
| 2026-04-18 | 4 |
| 2026-04-19 | 7 |
| 2026-04-20 | 2 |

Steady incidence across 9 days, no quiet stretches. The 2.1.98 downgrade reduces severity vs 2.1.101 but does not eliminate the bug.

What this implies

• Not Windows-specific — reproduced on Linux/SteamOS. The platform:windows label may be too narrow; suggest broadening or removing.
• Not bound to the 2.1.98–2.1.101 regression window — present on 2.1.114, ~16 versions newer than my Windows install. The regression label may understate scope; a clean version older than 2.1.98 would help bracket this.
• Not deployment-specific — both machines use --remote-control, but different OSes, different versions, different usage patterns (always-on service vs interactive local dev).
• Bash is disproportionately affected on both platforms (67% Windows, 100% Linux), but Windows shows the bug across every tool type in regular use — so this is not Bash-specific either; sample-size effects likely explain Linux’s narrower distribution.
• Parallel-batch trigger is real but not the whole story — clustered orphans account for 43% (Windows) and 29% (Linux) of the total. Most failures still happen on isolated calls.

Happy to share the orphan-detection script or specific session-file paths if useful for repro.

Follow-up — 9 more days of data on 2.1.98 (Windows native), and a live in-session reproduction

Adding a third structured update to this thread (prior: 4277566495, 4277660553). Same orphan-tool_use methodology — tool_use.id with no matching tool_result.tool_use_id in the same session JSONL.

Updated rate (Windows 11, Claude Code 2.1.98, native installer, autoUpdater disabled)

| Window | Sessions | tool_uses | Orphans | Rate |
|---|---|---|---|---|
| 2026-04-11 → 2026-04-20 (prior comment) | 25 | 4,420 | 51 | 1.15% |
| 2026-04-16 → 2026-04-30 (this update) | 36 | 4,631 | 68 | 1.47% |

The rate is getting worse, not better, on a binary that has not changed (autoUpdaterChannel: stable + DISABLE_AUTOUPDATER=1, byte-identical 2.1.98 the entire window). Whatever changed in the environment is on the API/wrapper side — local conditions are constant.

Tool breakdown (last 14 days, 68 orphans)

| Tool | Orphans | % |
|---|---|---|
| Bash | 46 | 68% |
| Agent | 8 | 12% |
| Edit | 5 | 7% |
| Write | 2 | 3% |
| Grep / WebSearch / ToolSearch | 2 / 2 / 1 | 7% |
| restart_claude_code (expected) | 2 | 3% |

49% of orphans cluster in parallel batches (orphans within ≤5 lines of each other in the same session JSONL). Up from 43%.

Two reproducible Bash sub-patterns

Within the 46 orphan Bash calls:

• 16 / 46 (35%) were piped through git-bash filters — 14 with | head, 2 with | grep
• 5 / 46 (11%) invoked Windows-native schtasks

These line up with the two failure modes I documented before: mixed-subsystem parallel batches, and Windows-native commands piped through git-bash filters.

Live in-session reproduction (today, 2026-04-30)

This very session (file 695ca3ec-30c2-4b1e-a99f-6a56d8323309.jsonl) hit 3 orphans across 73 tool_uses, captured both fault patterns, and required two manual interventions at the terminal:

| Line | Tool | Command | Pattern |
|---|---|---|---|
| 18 | Bash | ls -lt /t/QA_Dentaku/ \| head -20 | parallel batch (with line 20) |
| 20 | Bash | gh issue list --state open --limit 20 --json ... \| head -100 | parallel batch (with line 18) |
| 82 | Bash | schtasks /query /tn "*Watch*" /v /fo LIST 2>&1 \| head -60 | schtasks + git-bash pipe |

In all three cases, retrying the same call sequentially / unpiped worked first try. The Claude process itself stayed responsive (model continued reasoning between failures) — the break is exclusively in the tool-result delivery channel.

If a maintainer needs:

• raw orphan dataset (session_id, line, tool, input shape) for the 68 orphans — happy to attach
• the scanner script (orphan_scan.py) — happy to share
• traffic captures from a fresh repro — can produce on request

The platform:windows and regression labels on this issue are still inaccurate per the cross-platform Linux 2.1.114 evidence in 4277660553 — the bug is also present on Linux at a similar rate.

Recurrence — Claude Code 2.1.126 — Windows native (PowerShell tool, Git Bash via Bash tool)

Reproduced 4 times in a single ~75 min code session today (2026-05-02). All 4 surfaced as [Tool result missing due to internal error] with no partial state landing. Recovery via verify-state-then-retry (per CLAUDE.md guidance) worked every time, but cost ~14 min total in retry overhead and broke flow visibility — user had to interrupt twice to ask "are you stuck?" because the silent retry loop was indistinguishable from a hang.

Today's failures

| # | Tool | File | Lines | Content type | Recovery |
|---|---|---|---|---|---|
| 1 | Edit | src/constants/api.ts | +1 | URL constant, ASCII only | 1 retry → success |
| 2 | Write | src/utils/inviteCodeApi.ts | 85 | TS module with em-dashes (—) in JSDoc | 2 retries failed → 3rd attempt with em-dashes removed succeeded |
| 3 | Edit | src/App.tsx | +5 | import + Route, ASCII only | 1 retry → success |
| 4 | Edit | src/App.tsx | +5 | import line, ASCII only | 1 retry → success (separate event from #3) |

Total: 4 transport failures across ~15+ Edit/Write tool calls in the session. Edits succeeded first try outside these 4 events; the only file with 100%-failure-rate-until-content-changed was the 85-line Write.

Possible correlate (not conclusive)

The 85-line Write failed twice consecutively while content contained em-dashes (—) in JSDoc comments. Succeeded first try after replacing em-dashes with periods. Sample size too small to call this a deterministic trigger — the ASCII-only Edits also failed at a non-zero rate. But: em-dash content here failed 2/2 attempts (100%) while non-em-dash content failed at far lower than 100%. Worth investigating whether non-ASCII characters in the request body interact poorly with the transport layer.

What helps from the user side

• Following the existing CLAUDE.md "verify state via Read/git-status BEFORE retry" guidance prevented duplicate writes / corrupted state on every retry today.
• Smaller Edits (1-5 line diffs) appear more reliable than larger Writes — but this is also confounded with content type.
• Adopting "announce-on-first-failure" protocol (so user can see the retry loop instead of guessing whether the agent has hung) seems to be the right user-facing mitigation while the underlying bug is still in scope.

Asks

1. Any visibility into transport-layer logs that could correlate failures to specific request payloads? Today's data would let me test the em-dash hypothesis.
2. Is there an in-progress fix or workaround on the roadmap? Original issue is from a 2.1.101 regression; we're now on 2.1.126.

Repo and full session transcript can be shared privately if useful for triage.

Recurrence — Claude Code 2.1.126 — Windows 11 — Opus 4.7 (1M context) — cascades into remote-control teardown

Reproduced repeatedly: multiple Tool result missing due to internal error failures per session, every session, since Claude Opus
4.7 became default. The rate has been consistent enough across sessions that off-site work via remote control is currently
unworkable -- see "cascade" section below.

### Environment

• Claude Code: 2.1.126 (so post-2.1.101 regression and not fixed by anything since)
• OS: Windows 11 Pro for Workstations 10.0.26200
• Shell: PowerShell (the platform's harness shell, not git-bash)
• Model: claude-opus-4-7 (1M context)
• Notable settings: effortLevel: "high", remoteControlAtStartup: true, agentPushNotifEnabled: true,

skipDangerousModePermissionPrompt: true

• autoUpdaterChannel: stable

### Today's failures (single session, ~2.5h)
| # | Tool | Input shape | Recovery |
|---|------|------------|----------|
| 1 | Grep | absolute path N:\INTEGRIN\Framework\docs, single literal pattern | retry succeeded |
| 2 | Write | absolute path C:\Users\Stewart\.claude\projects\...\.md (~7KB body, ASCII) | retry succeeded |

Both calls used absolute Windows-native paths with no piping, no mixed-subsystem chaining, no non-ASCII characters in the
request. This rules out the git-bash-piping and schtasks correlates noted earlier in the thread as the only triggers — the bug
also fires on plain dedicated-tool calls (Grep/Write) with clean inputs.

### Cascade into #34255 (Remote Control teardown) — new signal
When Tool result missing due to internal error fires while the session is being driven via remote control, the
remote-control bridge does not survive the error: the websocket connection drops, no auto-reconnect, the off-site control surface
goes dead with no recovery from the remote side. Local terminal continues working; the model also continues reasoning between
failures (matching @DomTSM718's observation that the model itself stays responsive). But the remote operator sees a hang they
can't interrupt or re-attach to.

This makes the two issues effectively co-blocking for any user trying to oversee Claude Code from another device. Cross-linking
#34255 — the connection drop there is the same failure mode, but this thread's tool-result-missing event appears to be one of its
triggers.

### Asks

1. Any visibility into whether 1M-context Opus 4.7 sessions correlate with a higher transport-failure rate vs. 200K Sonnet?

Several other reports here are on Sonnet; this is the first I've seen explicitly noting Opus 4.7 1M.

1. If a fix is on the roadmap, can the remote-control bridge be made resilient to single tool-result drops (auto-reconnect rather

than tear down)? That would restore off-site usability before the underlying transport issue is fully fixed.

This bug is still reproducing on 2.1.139 (41 versions newer than the 2.1.98 baseline in my original report). Re-scanned my session JSONL using the same orphan-tool_use methodology from comment 4277660553 — a tool_use.id with no matching tool_result.tool_use_id in the same session, excluding expected orphans like restart_claude_code.

Fresh evidence — 14-day window (2026-05-08 → 2026-05-22)

| Metric | 2.1.98 baseline (April) | 2.1.139 now |
|---|---|---|
| Sessions scanned | 25 (Windows) | 51 (9 projects) |
| Total tool_use blocks | 4,420 | 5,851 |
| Orphans | 51 | 73 |
| Orphan rate | 1.15% → 1.47% (trending up) | 1.25% |
| Bash share of orphans | 67% | 82% |
| Parallel-batch clustering | 43% | 37% |

Per-project rate variance (new finding)

Light-use projects appear to be hit disproportionately. Same machine, same binary, same 14-day window:

| Project | Sessions | tool_uses | Orphans | Rate |
|---|---|---|---|---|
| (heavy use, single project) | 27 | 3,407 | 27 | 0.79% |
| (heavy use, second project) | 11 | 1,949 | 20 | 1.03% |
| (1-2 session projects, n=6) | 1–2 each | ~25–70 each | 2–5 each | 5.88% – 9.43% |

Could be a cold-start / first-session-of-cluster effect. The bug isn't uniform across the day or across projects.

Tool breakdown (global, 73 orphans)

| Tool | Count | % |
|---|---|---|
| Bash | 60 | 82% |
| Agent | 4 | 5% |
| Write | 3 | 4% |
| Edit | 2 | 3% |
| Grep | 2 | 3% |
| PowerShell | 1 | 1% |
| Read | 1 | 1% |

Bash dominance is more pronounced than the 2.1.98 baseline (67%). Windows PowerShell tool calls are also affected but rarer (we use Bash for most ops).

Live example from today

2026-05-22T04:58:42.277Z — PowerShell tool call in an active session. The orphan shows up as the "Tool result missing due to internal error" banner in chat, but the persistent signature is the orphan tool_use.id in JSONL. The session continued after the orphan, so it's not a session-killer — just a silent tool-result drop that wastes a roundtrip.

Mitigation rules still in effect (cost: real)

• Sequential tool calls preferred; parallel batches across subsystems avoided
• Glob/Grep/Read preferred over Bash for filesystem ops
• Never pipe schtasks/wmic through git-bash filters
• Cross-drive Glob/Write staged on C:\ first

These mitigations are working around the bug, not removing it. Without them the rate would be higher.

---

Happy to share session JSONL excerpts (redacted) or run additional probes if it would help narrow root cause. The bridge architecture means there's no client-side recovery — a tool result that drops is just gone.

Still reproducing on 2.1.153 — 14 versions newer than my last report (2.1.139), and now with a live, in-session capture.

Same orphan-tool_use methodology as my earlier comments (a tool_use.id with no matching tool_result.tool_use_id in the session JSONL; the rendered Tool result missing due to internal error string is injected at display time and not reliably persisted, so I scan the raw history instead).

Live capture — single session, pure 2.1.153, witnessed in real time

In one working session today (2026-06-06), two tool results dropped. Both surfaced as Tool result missing due to internal error; both are confirmed orphans in the JSONL:

| Time (UTC) | Tool | Command (truncated) |
|---|---|---|
| 16:05:14 | Bash | ls scratch/… && mkdir -p … (piped through head) |
| 20:57:10 | Bash | python diag/run_diag.py --no-rotate 2>&1 \| tail |

Session was 100% 2.1.153, 171 tool_uses, 2 orphans = 1.17%. Both were Git-Bash (Bash tool) calls piped through head/tail. In both cases re-running the identical command (or redirecting to a file instead of piping) succeeded — i.e. the tool executed; only the result-delivery channel dropped.

16-day aggregate (2026-05-22 → 06)

Re-scanned all projects on this host:

• Versions in window: 2.1.139, 2.1.142, 2.1.149, 2.1.153
• 63 sessions / 5,275 tool_uses / 74 orphans → 1.40% orphan rate
• Parallel-batch clustering: 55% of orphans (≤5 lines apart in the JSONL) — up from 37% in my 2.1.139 report
• Tool breakdown: Bash 54%, WebFetch 20%, PowerShell 8%, Write 5%, Read 4%, others ≤3%
• Per-project spread (7 of 9 affected): worst was a separate workspace at 3.79% (35/923); the heavy-use main project ran 0.97% (28/2,896)

The WebFetch share (20%) is new — in prior reports this was Bash-dominated. A research-heavy stretch this period drove a lot of WebFetch traffic, and the drops followed. So this is not Bash-specific; it tracks tool volume/concurrency more than any single tool.

Trend across versions (same methodology throughout)

| Version | Window | Orphan rate |
|---|---|---|
| 2.1.98 | Apr | 1.15% → 1.47% |
| 2.1.139 | May 22 | 1.25% |
| 2.1.139–2.1.153 | Jun 06 | 1.40% |

Roughly flat at ~1.2–1.5% across 55 releases since the 2.1.101 regression. Parallel batches and tool volume both correlate with higher rates, consistent with a result-delivery/transport race rather than a per-tool bug.

Happy to share the scan script or anonymized per-session orphan listings if that helps triage. Issue is still labeled regression + area:core; it has not improved on any version I've run.

New finding — this is two failure modes wearing one error message

Still reproducing on 2.1.153 (Windows 11 native, always-on --remote-control service,
Opus 4.7 1M sessions). Same orphan-tool_use methodology as my prior comments. But the last
three days produced evidence that the single signature — a tool_use.id with no matching
tool_result.tool_use_id — conflates two distinct failures, and they behave differently
under retry:

| | Type A — result-drop | Type B — request-drop |
|---|---|---|
| Did the tool execute? | Yes — side effects on disk | No — zero side effects |
| Evidence | 2026-06-06 live capture (4640439956): re-running the identical piped Bash command (or redirecting instead of piping) succeeded; the original had executed | 2026-06-10/11 live capture: 4 consecutive shell mutations (mkdir/cp via PowerShell tool ×2 and Bash tool ×2) produced no directory, no files — verified by read-back between attempts |
| Identical-command retry | Succeeds (Jun 6, both cases) | Failed back-to-back, twice on two separate occasions (PowerShell ×2 consecutive; later Bash cp ×2 consecutive) |
| What recovered it | Re-run / reshape the pipe | Switching tool class — the same file operations via the native Write/Edit tools succeeded immediately, every time |
| JSONL signature | identical (see below) | identical (see below) |

The shared JSONL signature: dead air

For all four Type B orphans (session b46cb359…, 2026-06-11T00:26:28Z, 00:31:34Z,
00:38:48Z, 00:44:42Z), the transcript shows the tool_use as the final record of its
turn — no progress record, no permission record, no error record, nothing — until a
queue-operation/user record minutes later when I manually interrupted:

line 663: ts=00:26:28.599Z type=assistant blocks=['tool_use']     <- orphan
   +1:    ts=00:31:15.244Z type=queue-operation                   <- me, typing, 4m47s later

A successful call in the same session for comparison: tool_use at 00:34:37.534Z →
tool_result 8 seconds later. Nothing about the orphan is distinguishable in JSONL except
the silence — the rendered Tool result missing due to internal error string is injected at
interrupt time, consistent with the render-time finding in
4277660553.

The prior day's session (9b669820…) shows the same dead-air shape on 6 orphans, including a
3-call parallel batch (Bash + Read + Bash within 1.1s, 2026-06-10T03:09:08–09Z) where the gap
to the next record was 73 minutes — that's the unattended-operation cost of this bug when
nobody is at the keyboard to Escape-interrupt.

Why this matters for triage: it narrows the search space

These are different code paths failing. Type B means the call never reached the local tool
runtime — no process was spawned, no side effect occurred. Type A means execution completed
and the result was lost on the way back. A fix aimed at the result-return path cannot fix
Type B, and vice versa.

Unifying hypothesis (offered as hypothesis, not fact): under the --remote-control
bridge architecture, tool calls are API-coordinated — each call has an outbound
dispatch/coordination leg and an inbound result leg. Type B = outbound leg drops (call
never dispatched); Type A = inbound leg drops (executed, result lost). One transport race,
two observable halves. It would also explain the contradictory recovery behavior I've now
captured on this host: "identical retry succeeds" (both Jun 6 Type A events) vs. "identical
retry fails consecutively until the approach changes" (both Type B pairs this week) — they're
different legs. If other reporters' events in this thread split the same way, that's
convergent; if not, this thread may be carrying more than one bug, which the sub-type
discriminator would also help untangle.

Testable prediction: sessions not using remote control should exhibit only Type A
(there is no coordination leg to lose). I can run a plain-terminal control period and report
back if useful.

Secondary observations from this week

• Within-window selectivity: the channel is selectively, not totally, dead. In one turn,

a read-only ls returned normally and the cp issued seconds later orphaned. But the
prior day's orphans were read-shaped (gh issue list, cat), so this is per-call
selection, not a read/write rule.

• Current rate: 1-day scan (2026-06-10→11): 2 sessions, 319 tool_uses, **10 orphans =

3.13%**, 50% parallel-batch clustered, tools Bash 7 / PowerShell 2 / Read 1. Highest rate
recorded on this host's heavy-use project (longitudinal baseline 0.97–1.47% since April).

• Methodology note for anyone replicating: classifying an orphan's sub-type requires

checking side effects before retrying — a successful retry overwrites the forensic
evidence (I lost one classification exactly this way: the retried command re-created the
output file ~6 minutes after the orphan, making the orphan's execution status
undeterminable). Dead-air duration (orphan tool_use timestamp → next session record) is
also worth capturing as the human-cost metric.

Asks

1. Does debug-level logging exist that stamps each leg of a tool call — request

dispatched / process spawned / result received? A single orphan captured with that trace
would pinpoint the failing layer definitively. Happy to run with any debug env vars or
flags on this host, which reproduces daily.

1. If the two-leg hypothesis is plausible to someone familiar with the wrapper internals,

the Type A/B split gives you a cheap repro discriminator: instrument the dispatch
acknowledgment and the result delivery separately.

1. Label hygiene, re-raised: platform:windows and regression remain inaccurate per the

Linux 2.1.114 reproduction in
4277660553
and 55+ versions of persistence. This is a live, cross-platform, ~1.2–3% transport-layer
loss on every tool call, with no maintainer response since April.

Raw session JSONL excerpts, the scanner script, and the side-effect verification timeline for
the four Type B orphans available on request.

Still reproducing on v2.1.178 (regression persists since 2.1.101).

Environment: Windows 10 Enterprise 19045 · Git Bash as the Bash-tool shell · model Opus 4.8 (claude-opus-4-8).

Pattern: intermittent across all tools (Bash/Read/Write/Edit), the entire tool result comes back as [Tool result missing due to internal error] — even for trivial read-only commands (ls, grep). The command often did run host-side; only the result fails to return. Worsens as a session gets long and tool-call-heavy; re-running frequently reproduces. The turn then either stalls on "Waiting…" forever or the model proceeds blind (dangerous for state-changing commands).

Frequency/impact: ~3–4 genuine >2-min stalls/day in our logs, 4th+ consecutive day. Background Agent/Task dispatches hang indefinitely when they hit a dropped result (observed a subagent sat 10+ min with a 0-byte transcript, had to be force-stopped).

Possibly-related signal under load: in the same sessions, codex invoked via the Bash tool repeatedly errors CreateProcessAsUserW failed: 1920 — a Windows process/sandbox-spawn failure under load that may share a root cause with the dropped results.

Note: there is no client-side setting that bounds this (verified vs docs), and Claude Code has no native detection/retry for a dropped tool_result — recovery currently requires a manual Esc + "continue". A built-in "tool_result not received within N s → retry/resync" would help a lot.

Another variant — deterministic, and IDE-specific. Windows 11, Claude Code 2.1.193, running inside a JetBrains/PhpStorm terminal with IDE integration active.

Here it's not intermittent or parallel. It splits 100% cleanly on whether the tool emits a diff against existing content:

• ❌ Always hangs → [Tool result missing due to internal error], change never applied: Edit, MultiEdit, and Write over an existing file.
• ✅ Always works: Read, Write of a new file, and the JetBrains plugin's own MCP edit tools (separate server).

/ide disconnect (or running Claude outside the IDE terminal) makes the failing tools work again. So with an IDE attached, the edit-diff round-trip through the IDE is a 100%-reproducible, single-call trigger — possibly a cleaner repro than the parallel-batch path, if they share a root cause.

Adding a data point from Windows 11 Pro (10.0.26200), Claude Code 2.1.193, Opus 4.8 — same OS build and same [Tool result missing due to internal error] marker as this report, but with one new finding the original (sequential) case doesn't cover: the drop rate scales super-linearly with the number of parallel tool calls in a single turn.

The OP notes their case is sequential / single-agent. I ran a controlled A/B varying only the parallel batch size (number of tool_use blocks emitted in one assistant turn), all read-only Grep/Read against a local repo, no MCP, no subagents:

| Parallel calls / turn | Turns | Total calls | Dropped | Per-call drop rate | Turns with ≥1 drop |
|---|---|---|---|---|---|
| 4 | 10 | 40 | 1 | 2.5% | 1/10 (10%) |
| 8 | 10 | 80 | 15 | 18.75% | 9/10 (90%) |

• 8-call turns dropped 1.5 results on average, up to 3 in a single turn.
• - Going 4 → 8 parallel raised the per-call failure ~7.5× — looks like a concurrency / result-pairing race, not only the sequential subprocess-cleanup theory.

Other observations that narrow it down:

• Position within the batch is random — first, middle, and last slots all dropped across different turns.
• - Tool-type independent — a homogeneous all-Read turn and a homogeneous all-Grep turn both dropped; not specific to mixing tool types.
• - - Always carries the marker, never a silently missing block — the number of returned tool_result blocks always equals the number of tool_use blocks; a dropped call is substituted in place with [Tool result missing due to internal error]. So it is detectable by scanning, and re-running only the dropped call succeeds immediately (usually first retry).
• - - - Not hooks — reproduced with all pre/post-tool-use hooks disabled (an orchestration layer's hooks fully off via env) at the same rate, which rules out hook interference.

Repro: emit N read-only Read/Grep calls in one turn and count how many tool_result blocks come back as the error marker; sweep N=4 vs N=8 over ~10 turns each.

Still present on 2.1.193, so the 2.1.101 regression (or a sibling of it) is not resolved. Happy to provide a transcript or /doctor dump.

Methodology correction + corroboration of the in-place ("proceed-blind") signature

Following up on my earlier Windows/Linux reports in this thread. This update does three
things: corrects my own earlier methodology claim, corroborates @JSKim-78's in-place
finding with a version-bucketed rescan, and reports back on two hypotheses others raised.

First, credit where it's due — the recent comments drove every bit of new analysis here:

• @JSKim-78 — the "substituted in-place, #tool_results == #tool_use" observation and the

controlled parallel-batch A/B. Both reproduced on my host (same OS build, Win 11 Pro 10.0.26200).

• @DomTSM718 — the non-ASCII / em-dash correlate, which I was able to test against ~10k calls.
• @toyuvalo — the "no native detection/retry for a dropped tool_result" point, which matches

what I hit live (below), and the CreateProcessAsUserW failed: 1920 signal.

• @ArtemGoutsoul — the IDE-attached deterministic Edit/Write repro; a much cleaner single-call

trigger than the parallel-batch path the rest of us have been chasing.

Correction: the sentinel is persisted on recent builds — as an in-place tool_result

In 4277660553
I claimed the Tool result missing due to internal error string is injected at render time and
not reliably persisted, and switched my canonical signal to the orphan tool_use (a
tool_use.id with no matching tool_result).

On current builds that is no longer true, exactly as @JSKim-78 described. The transport
increasingly does not drop the result entirely — it delivers a matching tool_result whose
content is the sentinel (same tool_use_id). My orphan-only scan pairs that result and counts it
as a success, so it was undercounting. The model receives the sentinel as if it were the
tool's output and proceeds blind.

So there are two on-disk signatures of one fault, and a rigorous scan must count both:

| | Signature | Behavior | When (my host) |
|---|---|---|---|
| A — orphan | tool_use with no matching tool_result | session hangs / dead-air; recover via Esc | dominant on 2.1.98–2.1.114 |
| B — in-place | matching tool_result whose content is the sentinel | no hang; model proceeds blind | first seen 2.1.142, ongoing |

Version-bucketed rescan counting BOTH signatures

I re-ran every retained session on this host through a detector that counts A and B, bucketed by
version (older April 2.1.98/2.1.114 sessions are pruned off disk, so this starts at 2.1.142):

| Version | Sessions | tool_uses | Orphan (A) | In-place (B) | Total rate | Orphan-only |
|---|---|---|---|---|---|---|
| 2.1.142 | 15 | 1,324 | 8 | 2 | 0.76% | 0.60% |
| 2.1.149 | 20 | 1,427 | 32 | 2 | 2.38% | 2.24% |
| 2.1.153 | 41 | 5,203 | 110 | 15 | 2.40% | 2.11% |
| 2.1.170 | 28 | 2,114 | 38 | 5 | 2.03% | 1.80% |
| Total | 104 | 10,068 | 188 | 24 | 2.11% | 1.87% |

Signature B is present on every retained version (earliest 2026-05-29 on 2.1.142). Orphan-only
undercounts by ~11% of all drops. Type B is the more dangerous mode for unattended / autonomous
use: there is no hang to catch, so a dropped result on a state-changing command silently becomes
"the model saw an error string and kept going."

On the parallel-batch dose-response (@JSKim-78)

I bucketed every drop by the size of its parallel batch (tool_use blocks sharing one message.id):

• single-call turns: 1.74% · parallel turns (≥2): 3.04% → parallelism ≈ 1.75× the

per-call drop rate. Directionally consistent with your A/B.

• I do not reproduce your clean super-linear curve in observational data — above batch size 3

my per-batch samples are too small to be reliable (e.g. batch=8 is 5/72). Your controlled A/B
(fixed N, homogeneous read-only) is the stronger design; my data corroborates the direction, not
the magnitude.

On the non-ASCII correlate (@DomTSM718)

Tested directly: dropped tool_use inputs carried non-ASCII (em-dashes etc.) 7.1% of the time
vs a 23.1% baseline across all calls — i.e. less often, not more. No support for the
em-dash correlation on my data. Caveat: my drops are Bash/PowerShell-dominated, which rarely carry
non-ASCII, so tool-mix likely confounds this — not a refutation, just no signal here. Your
JetBrains-IDE deterministic repro and @ArtemGoutsoul's may be a cleaner path to isolate it.

Live capture — and confirmation of @toyuvalo's "no native retry" point

While doing this analysis (2026-06-26) I hit signature B in real time on a gh pr create Bash call:
it returned [Tool result missing due to internal error]. The command had not executed (verified
no PR was created), I re-ran the identical command, and it succeeded first try — a clean Type-B
"request-drop" where the outbound leg was lost. As @toyuvalo notes, there is no built-in
"tool_result not received within N s → retry/resync"; recovery here was entirely manual
verify-then-retry. A native detector keyed on the in-place sentinel would be cheap to add and would
catch exactly this.

Ask (re-raised)

Per-leg debug logging (request dispatched / process spawned / result received) would let any of us
capture a single drop with a definitive trace. This host reproduces the in-place signature daily and
I'm happy to run with any debug env vars. The regression / platform:windows labels remain too
narrow per the cross-platform evidence earlier in the thread.