Plugin slash-commands return "Unknown command" in headless (-p) mode on 2.1.251 — regression from 2.1.250

Summary

Every plugin-provided slash command fails to resolve in headless mode on 2.1.251, returning Unknown command: /<plugin>:<cmd> with num_turns: 0. Built-in slash commands still work. The same commands resolve normally on 2.1.250 on the same machine, with the same plugins, the same config and the same working directory.

The failure is silent to callers: the process exits 0 with "is_error": false, so any wrapper checking the exit code sees success and gets an error string where a result should be.

Bisect

Identical command, identical cwd, adjacent versions, and crossed against two Node majors so the version is isolated as the only variable:

| | Node v20.19.3 | Node v24.14.0 |
| --- | --- | --- |
| 2.1.250 | resolves and runs | resolves and runs |
| 2.1.251 | Unknown command, num_turns: 0 | Unknown command, num_turns: 0 |

Each cell is a fresh npm i --prefix <tmp> @anthropic-ai/claude-code@<version> using that Node's own npm, then <prefix>/node_modules/.bin/claude -p '/ppp:show-in-viz' --output-format json. Nothing else differs between cells.

Node is worth crossing explicitly because package.json declares engines: {"node": ">=22.0.0"} and installing on Node 20 emits EBADENGINE. That warning is not the cause: bin/claude.exe is a ~214 MB ELF executable carrying its own runtime, so the declared engine governs npm's install-time check rather than what executes — which is why 2.1.250 works on Node 20, and why 2.1.251 fails on Node 24.

Scope

Plugin commands fail; built-ins are unaffected.

| Command on 2.1.251 | Result |
| --- | --- |
| /context (built-in) | works |
| /help (built-in) | "isn't available in this environment" — expected in -p |
| /ppp:show-in-viz (private marketplace, github source) | Unknown command |
| /ppp:analyze-incident (same) | Unknown command |
| /ai-dev:lint-skills (same) | Unknown command |
| /pr-review-toolkit:review-pr (claude-plugins-official) | Unknown command |

Both a private and the official marketplace are affected, so this is not specific to one marketplace or source type.

Reproduction

claude -p '/pr-review-toolkit:review-pr' --output-format json

from a project whose .claude/settings.json enables that plugin. Expected: the command runs. Actual: {"result":"Unknown command: /pr-review-toolkit:review-pr","num_turns":0,"is_error":false} in roughly 12 ms.

Plugin state was verified healthy

This is not a broken install. For ppp@sssss-plugins:

• enabled in the project's .claude/settings.json — "ppp@sssss-plugins": true
• present in ~/.claude/plugins/installed_plugins.json with an entry whose projectPath is the exact directory the command was run from
• the cached plugin exists and carries the command: ~/.claude/plugins/cache/sssss-plugins/ppp/0.13.0/commands/analyze-incident.md
• the installed version 0.13.0 matches the version in the marketplace clone

The same directory and the same plugin state produce a working command on 2.1.250 and a failing one on 2.1.251.

Impact

This broke an unattended service that shells out to claude -p /<plugin>:<command> to run an analysis. Because the process exits 0 with is_error: false, the service recorded the step as successful and stored the string Unknown command: /ppp:analyze-incident as its analysis result. It was caught only by an unrelated downstream sanity check on the output length. Any automation invoking plugin commands headlessly will silently substitute an error string for its result rather than fail.

Two things would each have contained it independently: resolving the command, or returning a non-zero exit / is_error: true when a command cannot be resolved.

Environment

• Claude Code 2.1.251 (broken) / 2.1.250 (works), installed via npm under nvm
• Node v20.19.3 and v24.14.0 both tested; the fault is present on both
• Linux 6.8.0-137-generic, x86-64
• The 2.1.251 binary arrived by auto-update at 2026-08-29 08:23 local time; the last successful headless plugin-command run on this machine was 2026-08-28 20:24 on the previous version. Rolling the global install back to 2.1.250 restored the behaviour immediately.

Not verified

Whether interactive (non--p) sessions are affected on 2.1.251 — the session available for testing predated the update, so this report covers headless mode only.