claude-code - 💡(How to fix) Fix [BUG] Skill tool broken in headless (`claude -p`) mode since v2.1.141 — returns is_error, skill body never loaded

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?

Since v2.1.141, the Skill tool no longer works in headless / print mode (claude -p). When a skill is invoked, the Skill tool call returns is_error: true and the skill body is never loaded into context — the tool result content is just the literal label Execute skill: <name>.

The exact same invocation works correctly in v2.1.140 and earlier. There the result is is_error: null with content Launching skill: <name> and the skill instructions are loaded as expected.

The skill itself is correctly registered — it appears in the session-init skills list and in slash_commands, the Skill tool is present in tools, and (for plugin skills) the plugin shows as connected. Nothing about discovery is broken; only execution in -p mode fails.

Interactive (TUI) skill invocation is unaffected. This is specific to non-interactive -p / --print runs, which is what breaks CI and orchestration workflows that depend on skills.

What Should Happen?

Invoking the Skill tool in claude -p should execute the skill and load its instructions into context — identical to interactive mode and identical to the behavior in v2.1.140 and earlier. The tool result should be is_error: null / Launching skill: <name>.

Error Messages/Logs

# Skill tool result in the stream-json output (v2.1.141, 2.1.142, 2.1.143):
{"type":"tool_result","is_error":true,"content":"Execute skill: figma:figma-use","tool_use_id":"toolu_..."}

# The model then gives up on the skill:
"The figma:figma-use skill failed to load."

# Same call on v2.1.140 and v2.1.139 (working):
{"type":"tool_result","is_error":null,"content":"Launching skill: figma:figma-use","tool_use_id":"toolu_..."}

Steps to Reproduce

1. Install/enable a plugin that ships a skill. I used the official figma plugin (v2.1.30), which provides the figma:figma-use skill. (A non-plugin user/project skill reproduces it just as well.)

2. Run a headless invocation that asks the model to call the Skill tool:

   claude -p 'Use the Skill tool to invoke the skill named "figma:figma-use" as your very first action, then report whether it succeeded.' \
     --output-format stream-json --verbose \
     --max-turns 4 --permission-mode acceptEdits \
     --setting-sources project,local \
     --model claude-haiku-4-5-20251001

3. Inspect the Skill tool result in the stream-json output.

   • v2.1.140 and earlier: is_error: null, content Launching skill: figma:figma-use, skill body loaded. ✅
   • v2.1.141, 2.1.142, 2.1.143: is_error: true, content Execute skill: figma:figma-use, skill body never loaded. ❌

I bisected every build between the last-good and current version with this identical repro:

Last good: 2.1.140. First bad: 2.1.141.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.140

Claude Code Version

2.1.143 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Non-interactive/CI environment

Additional Information

• Model-independent. Reproduced with both Opus and Haiku — this is a harness / tool-execution-layer issue, not a model behavior issue.
• Likely the same root cause as #59105. The 2.1.140 → 2.1.141 boundary lines up exactly with v2.1.141 reclassifying non-TTY claude -p runs as sdk-cli and diverging them from the interactive request scaffold. This report is a concrete, user-visible symptom of that change.
• Related (not duplicate): #58535 reports forked-skill dispatch breaking around v2.1.139–2.1.140 in the VS Code extension. That is a different surface (VS Code extension vs. CLI -p) and a different failure mode (Agent()-spawned subagent loses skill context vs. the Skill tool returning is_error), but it appears to be part of the same cluster of skill regressions in the v2.1.139–2.1.143 range.
• Impact. Any headless / CI / multi-agent-orchestration workflow that relies on skills silently degrades on 2.1.141+: the agent receives an error instead of the skill and proceeds without the guidance the skill was meant to inject. In my case, ~95 successful headless skill invocations across v2.1.112 → v2.1.139 all broke at once after upgrading to 2.1.143.