A project set up by the CLI, with plugins installed and reported installed, loads none of them under claude -p. The session runs, answers, and every skill it was supposed to use is silently absent.
What was measured
A throwaway project, set up entirely through the CLI — aidd setup, aidd marketplace add, aidd plugin install — each reporting success. A headless session was then asked to run three named skills in sequence. It ran, it answered, and it produced zero run files: no skill resolved. The Skill tool answered "Unknown skill" for all three, and the session hand-rolled the procedures by reading them off disk instead, which looks like success from the outside.
claude --debug-file names the cause in one line:
Skipping orphaned enabledPlugins entry ...: marketplace not registered
The project's .claude/settings.json carries the enabledPlugins entry the CLI wrote. Headless claude -p does not register the marketplace that entry points at, so the entry is orphaned and dropped — quietly, on stderr, behind a debug flag nobody passes.
Passing --plugin-dir <path> per plugin loads them and the same session resolves all three skills. So nothing is wrong with the plugins; what is wrong is that the installation the CLI performs is not the installation the headless runtime reads.
That failed session cost $1.27 and produced nothing.
Why it is worth a ticket of its own
This is the installation-path twin of the failure mode the measurement work exists to remove. Every visible signal says healthy: setup succeeded, plugin install reported success, the session ran and answered. The only tell is an absence — no skill resolved, and nothing said so.
It also lands hardest where nobody is watching. A person working interactively sees their skills missing and investigates. Anything headless — CI, an agent, a scheduled run — produces plausible output built without the skills it was meant to use, and no telemetry, and reports success.
Done when
- A project set up by the CLI loads its plugins under
claude -p, without a caller passing --plugin-dir.
- Or, if the runtime genuinely cannot register a marketplace headlessly, the CLI says so at install time and writes whatever the headless path does read.
- A session that resolved no skill from an installed plugin is distinguishable from one that needed none.
- A test fails when the two install surfaces disagree about which plugins load.
Bounds
Observed on one machine, on claude -p with a project-scope marketplace registered by the CLI. Whether an interactive session in the same project loads them was not tested — it is the obvious next probe and it separates "headless only" from "this project is broken".
Where it was found
Running the first real multi-step flow for the telemetry milestone (#694). The measurement layer was never the problem; it correctly reported nothing, because nothing happened.
A project set up by the CLI, with plugins installed and reported installed, loads none of them under
claude -p. The session runs, answers, and every skill it was supposed to use is silently absent.What was measured
A throwaway project, set up entirely through the CLI —
aidd setup,aidd marketplace add,aidd plugin install— each reporting success. A headless session was then asked to run three named skills in sequence. It ran, it answered, and it produced zero run files: no skill resolved. TheSkilltool answered "Unknown skill" for all three, and the session hand-rolled the procedures by reading them off disk instead, which looks like success from the outside.claude --debug-filenames the cause in one line:The project's
.claude/settings.jsoncarries theenabledPluginsentry the CLI wrote. Headlessclaude -pdoes not register the marketplace that entry points at, so the entry is orphaned and dropped — quietly, on stderr, behind a debug flag nobody passes.Passing
--plugin-dir <path>per plugin loads them and the same session resolves all three skills. So nothing is wrong with the plugins; what is wrong is that the installation the CLI performs is not the installation the headless runtime reads.That failed session cost $1.27 and produced nothing.
Why it is worth a ticket of its own
This is the installation-path twin of the failure mode the measurement work exists to remove. Every visible signal says healthy: setup succeeded,
plugin installreported success, the session ran and answered. The only tell is an absence — no skill resolved, and nothing said so.It also lands hardest where nobody is watching. A person working interactively sees their skills missing and investigates. Anything headless — CI, an agent, a scheduled run — produces plausible output built without the skills it was meant to use, and no telemetry, and reports success.
Done when
claude -p, without a caller passing--plugin-dir.Bounds
Observed on one machine, on
claude -pwith a project-scope marketplace registered by the CLI. Whether an interactive session in the same project loads them was not tested — it is the obvious next probe and it separates "headless only" from "this project is broken".Where it was found
Running the first real multi-step flow for the telemetry milestone (#694). The measurement layer was never the problem; it correctly reported nothing, because nothing happened.