feat(daemon): daemon status lists the registered provider plugins

[thymikee]

Summary

Part 2 of 4 of #3755 (umbrella #3747), stacked on #3767. Blocked by #3748: do not merge before it.

• agent-device daemon status [--state-dir <path>] [--json] reads daemon.json without contacting the daemon and lists every provider it registered (builtin/store/embedder, active/failed, typed error.reason). A record whose pid/start time no longer names a live process reports running: false.
• plugins list --json still works without a daemon (it lists store selections), and when a daemon runs for the same --state-dir it also returns that daemon's inventory under daemon.
• daemon and plugins schema, usage and help updated; daemon stays out of MCP (mcpExposed: false).

agent-device daemon status --json
agent-device plugins list --json

Not in this PR: the failed inventory entry inside the provider-not-registered error. #3748 owns that error, so I'll add the entry after rebasing onto it.

9 files.

Validation

pnpm check:affected --run --head 495046c784 (the stack top, which contains this layer): passed (exactCommit). CI owns integration, coverage and device lanes.

🤖 Generated with Claude Code

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://callstack.github.io/agent-device/pr-preview/pr-3768/
Built to branch gh-pages at 2026-10-17 05:24 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[github-actions]

Size Report

Metric	Base	Current	Diff
Installed (including dependencies)	5.35 MB	5.35 MB	+2.4 kB
Package (unpacked)	5.35 MB	5.35 MB	+2.4 kB
Package (download)	1.61 MB	1.61 MB	+812 B

Startup median (7 runs, lower is better):

Scenario	Base	Current	Diff
CLI --version	27.7 ms	27.8 ms	+0.1 ms
CLI --help	76.9 ms	79.9 ms	+3.0 ms

[cubic-dev-ai]

All reported issues were addressed across 9 files

_{You’re at about 93% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.}

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Turn on auto-fix | Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 4 files (changes from recent commits).

_{You’re at about 93% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.}

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Turn on auto-fix | Re-trigger cubic</sub>

[thymikee]

The code has one problem to fix before merge, and CI is green: 18 checks, 0 failing at 5645905. There are no conflicts.

readRecord and isTransport in daemon-status.ts add a third parser of daemon.json. The other two are readRegistration in daemon-registration.ts and readDaemonInfo in daemon-client-metadata.ts. isTransport copies readDaemonInfoTransport word for word, so the field schema (transport, version, plugins) now lives in two places and can drift. readRecord also catches every error and returns {}, which drops the absent/unreadable split that readRegistration keeps. If daemon.json exists but cannot be read (EACCES, I/O fault), daemon status prints "No running daemon for

." and plugins list leaves out the daemon inventory, even while a daemon serves that state dir. The rule: one owner in daemon-contracts parses daemon.json, and every reader uses it. Please move readDaemonInfo and its field readers into daemon-contracts next to readRegistration, or extend readRegistration to return the parsed record. Then build readDaemonStatus from that record and its registered, absent or unreadable status, delete readRecord and isTransport, and report "unreadable" instead of running: false. A test with an unreadable daemon.json should show that case.

Could readDaemonStatus become a small projection of registration status, the ownership check and readPluginInventory(record.plugins)? That would remove readRecord, the isTransport copy and the swallowed read error, and the CLI rendering and schema changes could stay as they are. The one thing that has to change first is a single daemon.json record reader in daemon-contracts, which daemon-client-metadata.ts then imports.

Not blocking, take or leave: plugins.md does not yet mention the daemon inventory that plugins list --json now returns (and line 20 still says an incompatible plugin stops the daemon from starting), so add one sentence or confirm a later stack PR owns it; and the em dash to hyphen change in the doc comment at daemon.ts:87 is unrelated and can be dropped.

Of the open inline threads, none still apply. All five are fixed at 5645905, so please resolve them: --clean only on stop, plugins flags per action, null start time, start-time JSDoc and plugins usage text.

No test here proves that a real daemon writes plugins into daemon.json; that write belongs to #3767, and every test here hand-writes the record. I did not rerun pnpm check:affected on the stack top, and I did not check whether a later stack PR owns the website page update and the changeset.

Before merge, one daemon-contracts reader must own daemon.json parsing for status, registration and client metadata. Merge also waits on #3748, as the PR body says.

[thymikee]

Thanks. Fixed in 8e5814d (stack top 7f449c5 passed pnpm check:affected --run).

• One daemon.json reader. readRegistration in daemon-registration.ts now also returns the parsed record. readDaemonStatus is a projection of it, next to the ownership check; daemon-status.ts, readRecord and isTransport are deleted. The transport reader is one function in daemon-resolution.ts that both readDaemonInfo and the status code use.
• Unreadable record. A record that exists but cannot be read is state: "unreadable" (daemon status says whether a daemon runs there is unknown, and plugins list notes it), no longer "No running daemon". DaemonStatus.state is running | stopped | unreadable; test added with an unreadable file.
• The inventory is carried raw in the status and validated with readPluginInventory where it is shown, which keeps the daemon-contracts closure within its budget.
• Dropped the unrelated em dash change.

On the docs sentence: plugins.md is owned by the stacked docs PR (#3769), which now covers plugins list inventory and the removed "incompatible plugin stops the daemon" line. A real daemon writing plugins is covered in #3767 (daemon-composition-credentials.test.ts asserts the composed inventory lands in daemon.json), and I saw it in a live run.

[thymikee]

The PR is ready at e886ff7. The earlier findings from #3768 (comment) are fixed, and I have no new blocking findings.

Not blocking: readDaemonInfo in https://github.com/callstack/agent-device/blob/e886ff7/src/daemon-client/daemon-client-metadata.ts#L110 still parses daemon.json with its own JSON.parse, so two parsers read one file, and later it could take the record from readRegistration; the unreadable state is tested only at readDaemonStatus, so one CLI test with a chmod-000 daemon.json could check the daemon status text and the daemonRecord:"unreadable" field from plugins list. You can take or leave both.

The five open cubic-dev-ai threads are fixed at this head, so you can resolve them: the daemon usage and flags (#3768 (comment)), the plugins flags (#3768 (comment)), the unreadable start-time case (#3768 (comment)), the readDaemonStatus JSDoc (#3768 (comment)), and the plugins usage text (#3768 (comment)).

All 15 checks pass at e886ff7, and there are no conflicts. This was a read-only review: I did not rerun pnpm check:affected or the tests, and I did not check that #3767 writes real daemon plugins into daemon.json or that #3769 updates plugins.md. Cubic has not reviewed this head. Merge now waits only on the stack order (#3767 as the base, and #3748 as the PR body says), and nothing in this change holds it up.