Skill tool intermittently returns "[Tool result missing due to internal error]"

Resolved 💬 3 comments Opened May 12, 2026 by IanVand Closed May 16, 2026

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.

View original on GitHub ↗

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