[BUG] [Tool result missing due to internal error] is unattributed, undiagnostic, and hangs the agent

Resolved 💬 2 comments Opened May 29, 2026 by MikeStitt Closed Jul 2, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] 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_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗