claude-code - 💡(How to fix) Fix Skill tool intermittently returns "[Tool result missing due to internal error]"

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…

In a long-running session, invoking the Skill tool occasionally returns [Tool result missing due to internal error] instead of executing the skill. Retrying with nearly identical arguments succeeds on the next attempt. Non-blocking, but I can't tell if it's a harness transient or something reproducible.

Filing this primarily to (a) leave a trace for the next person who hits it and (b) ask whether there's a log / correlation id I should capture if it recurs.

Error Message

In a long-running session, invoking the Skill tool occasionally returns [Tool result missing due to internal error] instead of executing the skill. Retrying with nearly identical arguments succeeds on the next attempt. Non-blocking, but I can't tell if it's a harness transient or something reproducible. [Tool result missing due to internal error]

  • ~/.claude/history.jsonl — has the user-prompt entries but no tool-error traces.
  1. Does the Skill tool write a log somewhere I haven't checked (beyond ~/.claude/logs/ and ~/.claude/debug/) that would capture the internal error context?
  2. If this is a known class of transient error, is there existing guidance (retry-with-backoff, clear-cache, restart-session) that's cheaper than re-invoking blindly?

Root Cause

I can't rule out either, and neither is a confident root cause.

Code Example

/deploy my-service-repo -- PR #63 merged to server01

---

[Tool result missing due to internal error]

---

/deploy my-service-repo PR #63 merged -- deploy to server01
RAW_BUFFERClick to expand / collapse

Summary

In a long-running session, invoking the Skill tool occasionally returns [Tool result missing due to internal error] instead of executing the skill. Retrying with nearly identical arguments succeeds on the next attempt. Non-blocking, but I can't tell if it's a harness transient or something reproducible.

Filing this primarily to (a) leave a trace for the next person who hits it and (b) ask whether there's a log / correlation id I should capture if it recurs.

Environment

  • Claude Code: 2.1.139
  • Platform: Windows 11, Git Bash shell
  • Model: Opus 4.7 (1M context)
  • Session was long (multi-hour, heavy tool usage across many subagents)

What happened

I invoked a user-authored skill (/deploy, which lives at ~/.claude/skills/deploy/SKILL.md) with:

/deploy my-service-repo -- PR #63 merged to server01

The tool returned, verbatim:

[Tool result missing due to internal error]

No partial output, no stack trace, no mention in stdout / stderr. The skill's SKILL.md file was readable and had not changed. I retried with nearly identical arguments (swapped the -- separator position):

/deploy my-service-repo PR #63 merged -- deploy to server01

It executed cleanly end-to-end.

What I checked

  • ~/.claude/logs/ — empty (no logs directory contents).
  • ~/.claude/debug/ — empty.
  • ~/.claude/history.jsonl — has the user-prompt entries but no tool-error traces.
  • Only one deploy SKILL.md exists on disk (not a plugin collision).
  • The skill's SKILL.md parsed cleanly on the retry; nothing had changed on disk between attempts.

Plausible but unproven theories

  1. Long-session context pressure. The session had been running for hours with heavy tool use; some harness-internal resource (memory, skill-cache, IPC) may have been in a bad state transiently.
  2. Argument parsing. The failing invocation had -- embedded mid-args. The succeeding invocation had -- at the end. If something in the skill-argument pipeline treats -- as a separator, that could plausibly trigger different code paths. Unconfirmed.

I can't rule out either, and neither is a confident root cause.

Questions for maintainers

  1. Does the Skill tool write a log somewhere I haven't checked (beyond ~/.claude/logs/ and ~/.claude/debug/) that would capture the internal error context?
  2. Is there a correlation id surfaced somewhere I could include next time this fires?
  3. If this is a known class of transient error, is there existing guidance (retry-with-backoff, clear-cache, restart-session) that's cheaper than re-invoking blindly?

Happy to capture additional data if this recurs — just let me know what to grab.

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