Tool result missing due to internal error — recurrent on Bash/Write + foreground PowerShell (Windows native)

Summary

Two distinct patterns of [Tool result missing due to internal error] returns mid-session, both appearing transport-layer (underlying operation typically completes on disk, but the response stream fails). Reproduced across separate sessions; both correlate with specific tool/call shapes; neither is explained by hooks, permissions, or any user-side configuration I've been able to identify.

Environment

• Claude Code 2.1.119
• Windows 11 Pro 10.0.26100 (native, not WSL)
• Shells: Git Bash (default for Bash tool) + Windows PowerShell 5.1 Desktop (the harness's PowerShell tool is hard-bound to powershell.exe — verified across claude --help, ~/.claude/settings.json, and env vars)

Pattern A — Bash + Write tool 26% failure rate (2026-04-25 session)

Session ID: 4c04ce00-1ad8-4263-b44c-b561d9eb79d9

19 of 72 tool calls returned [Tool result missing due to internal error]. Failed call shapes:

• Bash invocations of the shape ls -la "C:/Users/.../src/components/**/*" — quoted Windows paths + globs
• Write of TSX files in the ~7 KB range to absolute Windows paths

Recovery via Read or git status confirmed the underlying operations had typically landed (file written, ls would have succeeded). Retries with identical calls sometimes succeeded, sometimes failed identically. Hooks ruled out — failed call patterns don't match any pre-tool-use hook regex.

Anomalous vs baseline: of 39 historical sessions in the same repo, 37 had zero failures. Only one earlier session (2026-04-21, also signup-frontend repo work) had similar failures (5 occurrences).

Pattern B — Foreground PowerShell tool recurrence (2026-04-27 session)

Two consecutive foreground PowerShell tool calls returned [Tool result missing due to internal error]:

• Invoke-WebRequest against a staging API endpoint
• sqlcmd -S <azure-sql> -d <db> -Q "SELECT ..."

In the same session, background PowerShell calls (run_in_background: true) worked fine — including 2 successful long-running deploy.ps1 invocations. The tool-call shapes that failed were indistinguishable in command content from neighbouring successful calls; the only distinguishing factor was run_in_background: false vs true.

A visible UI status string during the failed calls read "Tempering… (50m 59s · ↓ 1.7k tokens)" — possibly a visible signal of the underlying degradation.

What's been ruled out

• Hooks — patterns in .claude/hooks/ don't match the failed call shapes
• Permissions — failed calls had identical permission paths to neighbouring successful calls
• PowerShell 5.1 quirks (2>&1 ErrorRecord wrapping, native-exe stderr, em-dash parser, etc.) — those are deterministic, produce different symptoms, and are documented internally; this transport pattern returns before script execution would have hit a 5.1 quirk
• Tool timeouts — affected Bash/Write calls are sub-second operations; not 120s timeout
• Output truncation — Bash calls had small output, Write calls were small files (well under 30k chars)

Local mitigations in place (not asking these to be replaced — context only)

• A diagnostic note documenting symptoms + recovery rules (PS 5.1 → 7 self-relaunch bootstrap for maintained scripts, prefer dedicated tools over Bash on Windows native, verify-state-before-retry rule)
• Decision-framework rule: prefer dedicated tools (Read, Write, Edit, Glob, Grep) over their Bash equivalents on Windows native
• Universal recovery rule: when [Tool result missing due to internal error] hits, verify state via Read / git status / DB query BEFORE retrying — the operation may have partially landed

What would help

• Transport-layer telemetry exposed to user. When this fires, is there a request ID or correlation token that surfaces in claude --diagnose or similar? Right now we see only the user-facing string with no actionable context.
• Foreground vs background tool path divergence (Pattern B). Suggests these go through different transport paths. If so, is there a known degradation in the foreground path on long sessions, or under specific load conditions? A configuration knob to force foreground-as-background for certain tool shapes would be a workable mitigation.
• Bash + Write on Windows native (Pattern A). Correlation with quoted Windows paths + small-file writes suggests possibly a path-encoding or stream-handling issue specific to those tool wrappers on Windows. (Switching to dedicated tools is what we do, but the failure mode existing at all is the bug worth filing.)

Happy to provide additional session IDs, targeted reproductions, or claude --diagnose output on request.