claude-code - 💡(How to fix) Fix [BUG] [Tool result missing due to internal error] is unattributed, undiagnostic, and hangs the agent

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Inside Claude Code v2.1.154 (macOS Darwin 25.2.0), long-running Bash tool calls intermittently return the literal string [Tool result missing due to internal error] to Problem 1 — The internal error itself missing due to internal error] to the agent. The commits did not land (git log HEAD unchanged), no orphan git or prek processes remained, and the /tmp/commit-out.log Problem 2 — The error doesn't identify the tool that generated it Most tools self-identify in their error messages: git: error: …, prek: error: …, pytest: ERROR: …. Anthropic-owned tooling should do the same. When the message is just result missing due to internal error] with no source prefix, it strongly suggests the message was written for internal (tool-to-tool, harness-to-agent) communication Example of the same anti-pattern elsewhere in the Claude Code ecosystem: https://github.com/anthropics/claude-code/issues/46767 — an unattributed error string that Convention to adopt: every Anthropic-emitted error string should be prefixed with the producing component (claude-code:, bash-tool:, harness:, mcp-router:, etc.), so Problem 3 — No diagnostic information accompanies the error The error string carries: — the error path should not be radically less informative than the success path. Problem 4 — The Claude CLI / agent loop hangs on the internal error instead of failing gracefully When the agent receives [Tool result missing due to internal error], the CLI's turn-handling continues as if waiting for more output, while the agent has no way to know The CLI should treat the internal-error result as a terminal failure of that one tool call, surface it cleanly to the user (with whatever diagnostic info problems 2 and Searching the file for internal error returns only three matches, all in agent-authored assistant messages quoting the symptom; the harness never wrote a structured error row error] and following the natural "go look at the latest debug log" instinct lands on a dangling pointer with no breadcrumbs. A failed tool call should return a self-identified, diagnostically-rich error and unblock the agent / CLI cleanly.

Error Messages/Logs

[Tool result missing due to internal error]

Code Example

[Tool result missing due to internal error]
RAW_BUFFERClick to expand / collapse

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

Inside Claude Code v2.1.154 (macOS Darwin 25.2.0), long-running Bash tool calls intermittently return the literal string [Tool result missing due to internal error] to the agent. This single failure mode bundles four distinct defects, each fixable independently.


Problem 1 — The internal error itself

After three consecutive ~30-second git commit invocations (each triggering ~33 prek pre-commit hooks, output piped through tail -30/tail -60), all three returned [Tool result missing due to internal error] to the agent. The commits did not land (git log HEAD unchanged), no orphan git or prek processes remained, and the /tmp/commit-out.log that the third attempt was supposed to redirect into was never created — strongly suggesting the underlying shell never ran on that attempt. Something in the Bash transport path is failing and dropping results.

Problem 2 — The error doesn't identify the tool that generated it

Most tools self-identify in their error messages: git: error: …, prek: error: …, pytest: ERROR: …. Anthropic-owned tooling should do the same. When the message is just [Tool result missing due to internal error] with no source prefix, it strongly suggests the message was written for internal (tool-to-tool, harness-to-agent) communication where the developer assumed the reader already knows the source — which is the wrong assumption once the string surfaces to a human or to the model.

Example of the same anti-pattern elsewhere in the Claude Code ecosystem: https://github.com/anthropics/claude-code/issues/46767 — an unattributed error string that turned out to come from an Anthropic component but gave the user no way to know which one.

Convention to adopt: every Anthropic-emitted error string should be prefixed with the producing component (claude-code:, bash-tool:, harness:, mcp-router:, etc.), so both humans reading the transcript and the model deciding how to react know who said it.

Problem 3 — No diagnostic information accompanies the error

The error string carries:

  • no exit code
  • no PID of the child process
  • no elapsed time
  • no indication whether the underlying shell command started, completed, or never ran
  • no log path to inspect
  • no correlation ID for filing a follow-up

This makes the failure unactionable for the user and unrecoverable for the agent. Compare to the structure a normal Bash tool result has (stdout, stderr, exit code, duration) — the error path should not be radically less informative than the success path.

Problem 4 — The Claude CLI / agent loop hangs on the internal error instead of failing gracefully

When the agent receives [Tool result missing due to internal error], the CLI's turn-handling continues as if waiting for more output, while the agent has no way to know whether to retry, abandon, or wait. In my session the loop effectively stalled — I had to open a second terminal, run ps aux | grep pytest to confirm nothing was actually hung at the OS level, and message back via /btw to ask the agent what was going on. The agent then speculated incorrectly about a commit-msg hook rejection, and the only forward progress came from user intervention.

The CLI should treat the internal-error result as a terminal failure of that one tool call, surface it cleanly to the user (with whatever diagnostic info problems 2 and 3 add), and let the agent / user resume without a manual unstick.


Evidence on disk

If diagnostics are needed from my machine:

  • Session JSONL (full transcript including all is_error: true tool results from this run): /Users/mikestitt/.claude/projects/-Users-mikestitt-projects-fab-ri-na-tor-2mesh-atlas/61017883-03a6-4440-9728-87486ee21d1f.jsonl — 1,239,500 bytes, last modified 2026‑05‑29 11:04. Searching the file for internal error returns only three matches, all in agent-authored assistant messages quoting the symptom; the harness never wrote a structured error row of its own. That gap is itself evidence for Problems 2 and 3.
  • Broken ~/.claude/debug/latest symlink — supporting evidence for Problem 3 (the CLI's own diagnostic surface is unmaintained):

$ ls -la ~/.claude/debug/ total 0 drwxr-xr-x 3 mikestitt staff 96 Apr 15 10:27 . drwxr-xr-x 22 mikestitt staff 704 May 29 11:04 .. lrwxr-xr-x@ 1 mikestitt staff 71 Feb 25 08:09 latest -> /Users/mikestitt/.claude/debug/fdc2bbd9-84c8-4dc0-97fa-549535c6accd.txt

$ readlink ~/.claude/debug/latest /Users/mikestitt/.claude/debug/fdc2bbd9-84c8-4dc0-97fa-549535c6accd.txt

$ test -e ~/.claude/debug/latest && echo present || echo MISSING MISSING

  • The "latest debug log" symlink was last touched 2026-02-25 and points at a file that no longer exists. Either the cleanup task that deleted the target should also have updated/removed the symlink, or some other process is meant to keep it pointed at a real file. Either way, a user (or agent) hitting [Tool result missing due to internal

error] and following the natural "go look at the latest debug log" instinct lands on a dangling pointer with no breadcrumbs.

  • Missing /tmp/commit-out.log — corroborates that the third git commit attempt never ran its redirect to /tmp/commit-out.log (the file does not exist), so the failure is "shell never started" rather than "shell ran and Bash transport dropped the result mid-stream".

Repro shape (the trigger we hit)

  • macOS Darwin 25.2.0, Claude Code v2.1.154, Opus 4.7
  • Bash tool call running git commit with a ~50-line Conventional Commit message passed via cat <<'EOF' … EOF heredoc
  • ~33 prek pre-commit hooks running, ~30s wall time
  • Output piped through | tail -30 or | tail -60
  • Session ID 61017883-03a6-4440-9728-87486ee21d1f

What Should Happen?

Expected

A failed tool call should return a self-identified, diagnostically-rich error and unblock the agent / CLI cleanly.

Actual

Bare unattributed string, no diagnostics, agent stalled until human intervention.

Error Messages/Logs

[Tool result missing due to internal error]

Steps to Reproduce

Unknown.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.156 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] [Tool result missing due to internal error] is unattributed, undiagnostic, and hangs the agent