workers inject-context: --json emits 0 bytes (unparseable) and the command can never find context (in-memory registry)

Summary

workers inject-context produces zero bytes of output for every input, including with --json, where an empty string is not valid JSON and crashes any consumer that parses it. Underneath that, it reads the in-memory per-process worker registry (#182), so it can never find anything to inject when run from the CLI or a hook.

Measured on 2.1.2. (Absent on @alpha — see #208 §3.)

1. --json emits nothing, so JSON.parse throws

Cause — dist/cli/commands/workers.js:579:

const relevant = completed.filter(...);
if (relevant.length === 0) {
    // No context to inject
    return;            // <-- returns before the --json branch
}

Silence is the right behaviour for the plain/hook path — the command is documented as "hook-optimized, silent", and emitting nothing when there is nothing to inject is correct there. But when --json is passed the caller has explicitly asked for a machine-readable result, and "" is not one. Every other --json in this CLI emits a document.

Suggested fix: when options.json, print [] (or {"context": []}) before returning. Compare workers status --json, which correctly emits [] for an empty registry.

Related: workers cleanup --json also emits 0 bytes, and additionally exits 1 — noted in #182. These are the only two --json flags in the command group that produce nothing.

2. It can never find anything anyway

const registry = getWorkerRegistry();
const completed = registry.getAll({ sessionId: options.session, status: 'complete', limit: 50 });

That is the same in-memory, per-process registry as #182. A hook or CLI invocation starts a fresh process, so completed is always [] and the keyword match at line 574-578 never has anything to match against. relevant.length === 0 is not an edge case here — it is the only reachable state.

So the two defects compound: the command is structurally guaranteed to hit exactly the branch that emits nothing. Fixing #182's persistence would make this command functional and would also make the --json gap visible in normal use rather than only in the empty case.

3. Note on the documented hook wiring

The docs suggest wiring worker commands into UserPromptSubmit via npx agentic-flow@alpha workers dispatch-prompt "$USER_PROMPT" .... Two problems worth flagging alongside this issue:

• workers does not exist on @alpha, so the hook prints 12,236 bytes of the top-level usage screen at exit 0. UserPromptSubmit hook stdout is injected into the model's context in Claude Code, so that usage screen is prepended to every prompt.
• $USER_PROMPT / $SESSION_ID are not populated — Claude Code delivers hook data as JSON on stdin, not environment variables (same error as the $TOOL_INPUT_* wiring generated by hooks init, #207). Pointed at the working 2.1.2 binary, the hook runs against an empty prompt: {"dispatched":false,"triggers":[],"workerIds":[]}.

Environment

agentic-flow 2.1.2 (global), Node 24, macOS 15.6, run in an empty scratch directory.

Start with dist/cli/commands/workers.js around lines 574-579 and compare workers status --json; reproduce inject-context with and without --json to establish the empty-output behavior. Then trace getWorkerRegistry() and the #182 persistence issue, plus the documented UserPromptSubmit wiring; done means machine-readable empty output and worker context lookup across CLI or hook processes, with hook input read as JSON.