claude-code - 💡(How to fix) Fix [BUG] Tool results silently dropped with "missing due to internal error" across all tools on Windows (regression in 2.1.101) [2 comments, 2 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Summary

Claude Code 2.1.101 on Windows 11 (native installer) silently drops tool results for a significant fraction of tool calls. The dropped results surface to the model as "Tool result missing due to internal error" — a wrapper-level failure, not a tool-level error. It affects every tool I've exercised: Bash, Glob, Read, Write, WebFetch. Three days of productivity lost so far; ~7-8 dropped results in a single working day.

Environment

• Version: 2.1.101 (latest on npm as of 2026-04-11)
• OS: Windows 11 Pro 10.0.26200
• Install method: native (~/.local/bin/claude.exe, versions at ~/.local/share/claude/versions/)
• Shell: Git Bash
• autoUpdatesChannel: latest
• Configured "autoUpdates": false in .claude.json did NOT prevent the upgrade to 2.1.101 (native installer appears to ignore this field; only env.DISABLE_AUTOUPDATER in settings.json is honored).

Symptom

Tool call → immediate return with "Tool result missing due to internal error". No stall, no hang, no timeout. The tool either never ran or ran but its result was discarded on the way back to the model. Model then has no result to continue from and has to retry or the session must be reset.

Distributed across tools — not a single-tool regression:

• Bash ls — failed
• Glob — failed (cross-drive and same-drive)
• Write — failed (also confirmed the side effect did not occur)
• WebFetch to https://registry.npmjs.org/@anthropic-ai/claude-code — failed (happened live while I was diagnosing this very bug)

Scoping data

I ran a scan over 163 session transcripts at ~/.claude/projects/<proj>/*.jsonl for the 8-day window 2026-04-04 through 2026-04-11, searching for the "missing due to internal error" wrapper string.

Result: the wrapper error appears in exactly 2 session files, BOTH on 2026-04-11 — the day 2.1.101 landed on the machine. Versions present in transcripts earlier in the week (2.1.84, 2.1.85, 2.1.86, 2.1.92) do not show the pattern.

One affected session had 5 of 15 tool_use blocks with no matching tool_result (33% drop rate).

Suspected cause

The 2.1.101 changelog has several bullets touching subprocess/tool-result lifecycle. My top suspect:

Improved SDK query() to clean up subprocess and temp files when consumers break from for await or use await using

A subprocess lifecycle refactor is the exact shape of bug that would drop tool results — if the cleanup path now fires before the result is delivered back, the wrapper would see nothing to forward and surface the generic "missing due to internal error" message.

Adjacent suspects from the same release:

• "Fixed a crash on --resume when a persisted Edit/Write tool result was missing its file_path" — active work on tool-result persistence
• "Fixed sandboxed Bash commands failing with mktemp: No such file or directory" — subprocess sandbox fix

Note that 2.1.98 introduced subprocess sandboxing as a feature. 2.1.101 is the first release with follow-up fixes in that subsystem. Classic regression shape.

Reproduction

Not cleanly reproducible on demand — the drop rate on this machine is ~10-30% of tool calls once it starts happening in a session, which is enough to make the session unusable but not enough to hit on every call. Happy to share a raw session transcript with the Anthropic team privately if that helps.

Workaround

Downgrading to 2.1.98 via the official install script:

& ([scriptblock]::Create((irm https://claude.ai/install.ps1))) 2.1.98


### What Should Happen?

## Expected behavior

When a tool is invoked, one of these should happen:

1. **Success:** the tool executes and its result (stdout/stderr/structured
   output) is delivered to the model. The model sees the real content.
2. **Tool-level error:** the tool fails with an actionable error — exit code,
   timeout, file-not-found, permission denied, etc. The model sees *why* it
   failed and can retry or change approach.
3. **Unrecoverable harness error:** if the wrapper layer itself fails to
   marshal the result, the session should either (a) automatically retry the
   tool call a bounded number of times, (b) surface a structured error
   identifying the wrapper failure (not a silent string), or (c) abort the
   turn with a visible diagnostic the user can act on.

**What's currently happening:** the model receives the literal string
`[Tool result missing due to internal error]` as if it were a valid tool
result. The tool either never ran, or ran but its output was discarded
before reaching the model. There is no retry, no exit code, no stderr, no
indication of which layer failed. The session silently loses forward progress
until the user manually resets or steers Claude to try a different approach.

This is especially harmful because:
- It's indistinguishable from a real tool result to the model's next-turn
  reasoning, so the model often hallucinates what the tool would have
  returned rather than surfacing the failure.
- There's no log entry or telemetry the user can grep for after the fact —
  the only evidence lives inside the session transcript.
- There's no user-visible signal that anything is wrong until progress stalls.

### Error Messages/Logs

```shell
## Error messages and logs

### The wrapper error itself

The exact string surfaced to the model, observed multiple times in 2026-04-11:
[Tool result missing due to internal error]


It appears inline where a normal tool_result block would have been. No stderr,
no exit code, no timestamp, no layer identifier.

### Concrete observations from today's session

1. `Bash ls -la "C:/Users/the_robot/.local/bin/claude.exe"` → wrapper error
2. `Bash ls -la "C:/Users/the_robot/.claude/"` → wrapper error (same message)
3. `Bash ls -la "C:/ai-agent/rc-startup.log" ...` → wrapper error
4. `WebFetch https://registry.npmjs.org/@anthropic-ai/claude-code` → wrapper
   error (this one is particularly diagnostic — it's a plain HTTPS fetch, no
   subprocess, no filesystem, no Windows-specific path. It still hit the
   bug. That rules out "Windows command shape" as the root cause and points
   at the tool-result delivery layer itself.)

On retry, some of these calls *did* succeed — the Bash `ls` cases remained
broken session-long, but the WebFetch succeeded when retried with a smaller,
simpler URL (`.../claude-code/latest` instead of the full package metadata).
This suggests a size/latency-sensitive path, not a hard break.

### Session transcript evidence

Scan of `~/.claude/projects/<proj>/*.jsonl` for the 8-day window
2026-04-04 → 2026-04-11, searching for the wrapper error string:

| Day | Version active | Wrapper errors |
|-----|---------------|----------------|
| 04-04 to 04-10 | 2.1.84 → 2.1.92 | 0 sessions |
| 04-11 | **2.1.101** | **2 sessions, 5+ dropped tool_results** |

One affected session had 15 tool_use blocks and only 10 matching tool_result
blocks (33% drop rate). Worst case the session became unusable and had to be
reset.

### No Claude Code debug log

I could not find a Claude Code internal log surfacing the underlying exception.
`~/.claude/` and `~/.local/share/claude/` contain no error log or crash dump
for these events. If there is a debug mode that would capture the underlying
exception (`CLAUDE_CODE_DEBUG=1`, a log file path, etc.), point me at it and
I'll reproduce with it on and attach the output.

Steps to Reproduce

Reproduction

Not cleanly reproducible on demand — the drop rate on this machine is ~10-30% of tool calls once it starts happening in a session, which is enough to make the session unusable but not enough to hit on every call. Happy to share a raw session transcript with the Anthropic team privately if that helps.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.98

Claude Code Version

2.1.101

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Related existing issues

• #43866 — Same "Tool result missing due to internal error" string, but scoped to the Skill tool only. Our report may share a root cause; the 2.1.101 regression might have expanded the blast radius from Skill-only to all tools. Worth cross-linking during triage.
• #39830 — Parallel Agent calls losing tool_results. Different shape (ours is sequential, single agent, no parallelism) but adjacent failure class.
• #44068 — Closed-as-duplicate proposal to auto-retry on this error, suggesting the error class is already tracked somewhere, though I couldn't find the canonical parent issue.