Daily review findings: 2026-06-08

[garethpaul]

I reviewed the current main branch and found 5 issues worth triage. I checked these against open and closed GitHub issues before filing.

1. Memory read commands prepend CLI intros to stdout data

Area: poe-code
Severity: medium
Confidence: high
Score: 74

What I found:
The memory read/status commands mix two output contracts on stdout. They create execution resources and call logger.intro(...), then immediately write raw command payloads with process.stdout.write(...).

That is especially problematic for memory show, whose description promises to print a page to stdout. In production the page content is preceded by the intro header, while nearby tests inject a logger emitter and only assert the raw write calls, so they do not catch the combined user-visible stream.

Rechecked against origin/main at b1579e053b4654073b55215899dea22bcc6c277a: the same resources.logger.intro(...) calls still happen before the direct process.stdout.write(...) payloads in ls, show, search, and status.

Evidence:

• src/cli/commands/memory.ts:156-180 calls resources.logger.intro("memory ls") before writing page list lines directly to process.stdout.
• src/cli/commands/memory.ts:182-201 documents memory show as "Print a page to stdout" but calls resources.logger.intro("memory show") before writing the raw page file content.
• src/cli/commands/memory.ts:215-238 calls resources.logger.intro("memory search") before writing path:line:match rows directly to process.stdout.
• src/cli/commands/memory.ts:420-449 calls resources.logger.intro("memory status") before writing Pages, Bytes, token counts, and missing sources directly to process.stdout.
• src/cli/logger.ts:197-207 emits intro output through the design-system intro primitive when no test emitter is injected, so the header is a real stdout write in production CLI runs.
• src/cli/commands/memory-command.test.ts:133-174 asserts only the raw ls and show process.stdout writes while the test container injects a logger emitter, masking production intro output.
• src/cli/commands/memory-command.test.ts:200-214 similarly asserts only raw search rows and does not cover the combined production stdout stream.

2. CLI logger bypasses design-system JSON and Markdown output modes

Area: poe-code
Severity: medium
Confidence: high
Score: 72

What I found:
The shared poe-code logger has special non-terminal branches that write raw strings directly to stdout. That bypasses the design-system log primitives, even though those primitives already know how to render Markdown bullets and JSON records.

The result is that OUTPUT_FORMAT=json or OUTPUT_FORMAT=markdown cannot be trusted for normal command status output. A command can render an intro/outro or table through the design system, then emit plain logger lines in the middle of the same output stream.

Evidence:

• src/cli/logger.ts:1-9 imports design-system primitives but also imports chalk directly for shared logger styling.
• src/cli/logger.ts:82-107 writes plain message + "\n" whenever resolveOutputFormat() is not terminal, bypassing design-system log.info/success/warn/error handling.
• src/cli/logger.ts:130-140 and 208-218 write label: value directly for resolved/errorResolved in non-terminal modes instead of the design-system structured message renderer.
• src/cli/logger.ts:183-195 does the same for verbose output, so verbose logs also ignore JSON/Markdown output behavior.
• packages/design-system/src/prompts/primitives/log.ts:60-138 already implements markdown bullets and JSON records for message/info/success/warn/error.
• docs/DESIGN_LANGUAGE_JSON.md:51-75 documents OUTPUT_FORMAT=json as NDJSON for the standard layout.
• src/cli/commands/shared.ts:350-370 wires this logger into command execution resources, and src/cli/context.ts:77-96 routes dry-run operation output through logger.info.
• src/cli/logger.test.ts:13-24 mocks resolveOutputFormat to always return terminal, so the non-terminal behavior is not covered by nearby tests.

3. Managed host processes can be orphaned when the launcher daemon disappears

Area: @poe-code/process-launcher
Severity: medium
Confidence: high
Score: 72

What I found:
stopManagedProcess contains a host child-pid fallback, but current normalization prevents that branch from running. readManagedProcess() calls normalizeRecord(), and normalizeRecord() converts any active record whose daemon pid is not running into a stopped/crashed state. That clears state.pid before stopManagedProcess() reaches the fallback that would signal the recorded host child pid.

Rechecked against origin/main at b1579e053b4654073b55215899dea22bcc6c277a: the process-launcher symlink fixes and later agent-eval plan-destination fix did not change this behavior. The stale-daemon branch still clears state.pid during normalization before stopManagedProcess can use its host child fallback.

In the failure mode where the supervisor daemon dies but the spawned host process survives, poe-code launch stop can report the managed process as stopped without terminating the actual long-running child.

Evidence:

• packages/process-launcher/README.md:1-3 - The package is the CLI-facing supervisor for long-running host and Docker dev tools.
• packages/process-launcher/src/launcher.ts:132-155 - stopManagedProcess has a fallback intended to signal record.state.pid for active host processes when the daemon pid is unavailable.
• packages/process-launcher/src/launcher.ts:464-483 - readManagedProcess normalizes every active record with a non-running daemon pid into createStoppedState before stopManagedProcess sees it.
• packages/process-launcher/src/launcher.ts:486-496 - createStoppedState clears the recorded child pid and marks the process stopped/crashed based only on prior exit code.
• packages/process-launcher/src/process-launcher.test.ts:272-310 - The stale-running stop test only covers signaling a live daemon pid, not a dead daemon with a still-running host child pid.
• packages/process-launcher/src/process-launcher.test.ts:413-438 - The listing test asserts stale daemon records are marked stopped when isPidRunning is false for every pid, but there is no nearby test for daemon false and child pid true.

Suggested next step:
Keep enough active host state through readManagedProcess() for stopManagedProcess() to signal state.pid when daemonPid is missing or dead and state.runtime === "host". Add a regression test with daemonPid not running, state.status: "running", state.pid running, and assert signalProcess(state.pid, "SIGTERM") is called before the record is marked stopped.

4. eval commands ignore toolcraft --output modes

Area: @poe-code/agent-eval
Severity: medium
Confidence: high
Score: 70

What I found:
The forwarded poe-code eval commands expose toolcraft's global --output option, but the eval handlers bypass toolcraft rendering. They write stdout inside the handler, return null, and then install empty rich/markdown/json render overrides, so the selected toolcraft output mode has no chance to shape the result.

eval report has a separate --format flag that can print JSON or Markdown, but that does not fix the advertised --output contract. eval run, dry-run previews, init, check, and lint have the same direct-write pattern and no equivalent output-mode handling.

Evidence:

• packages/toolcraft/src/cli.ts:1955-1967 registers the global --output <format> option for toolcraft commands, including rich, md/markdown, and json.
• packages/toolcraft/src/cli.ts:2125-2150 resolves --output and maps it into design-system OUTPUT_FORMAT before the handler runs.
• packages/toolcraft/src/cli.ts:3720-3793 runs handlers inside that output mode and then calls renderResult for the selected mode.
• packages/toolcraft/src/renderer.ts:416-438 shows renderResult honoring command json, markdown, and rich renderers or falling back to auto rendering.
• packages/agent-eval/src/cli/commands.ts:141-177 writes dry-run text and streaming run tables directly to stdout, returns null, and defines empty/undefined renderers, so eval run --output json cannot emit JSON.
• packages/agent-eval/src/cli/commands.ts:225-244 prints reports through printMatrixReport/printRunsReport, returns null, and disables renderers, so toolcraft --output is ignored in favor of the command-local --format default.
• packages/agent-eval/src/cli/commands.ts:253-300 repeats the same direct-write plus disabled-renderer pattern for eval init and eval check dry-run output.
• packages/agent-eval/src/cli/commands.ts:370-414 manually writes JSON/Markdown/table report formats from --format, proving output formatting lives outside the active toolcraft output mode.
• packages/agent-eval/src/cli/cli.test.ts:113-126 and 220-238 assert direct stdout behavior and argument parsing, but there are no nearby tests for --output json, --output md, or JSON/Markdown suppression of terminal output.

5. Codex configure accepts the default reasoning effort without --yes

Area: poe-code
Severity: medium
Confidence: high
Score: 69

What I found:
Codex declares Codex reasoning effort as a configure prompt and the CLI exposes --reasoning-effort, but the resolver always supplies the default as a fallback. The generic ensure helper returns that fallback before invoking prompts, so an interactive configure run never asks for reasoning effort unless the user already supplied the option.

This differs from the model resolver, which only accepts the default when assumeDefault is true, there is a single choice, or the user answers the prompt.

Evidence:

• src/providers/codex.ts:149-157 declares a Codex reasoningEffort configure prompt with label Codex reasoning effort and a default value.
• src/cli/commands/configure.ts:41-64 exposes the equivalent non-interactive CLI argument as --reasoning-effort <level>.
• src/cli/prompts.ts:95-101 defines a text prompt descriptor for reasoningEffort, including the default as the prompt initial value.
• src/cli/commands/configure-payload.ts:106-113 resolves the Codex reasoning prompt whenever the provider declares it.
• src/cli/options.ts:82-90 returns input.fallback before prompting, and src/cli/options.ts:236-248 always passes fallback: defaultValue for resolveReasoning.
• src/cli/commands/configure.test.ts:122-132 mocks resolveReasoning as defaultValue, so nearby configure tests do not catch the missing interactive prompt.

Duplicate checks

• Refreshed issue cache for poe-platform/poe-code before preparing this issue.
• Prepared at 2026-06-08T07:00:21.871Z.
• Checked candidate metadata for duplicate links and exact GitHub title matches.
• Source candidates are stored under /home/gjones/poe-code-issues/candidates.

[garethpaul]

Update: item 3, "Managed host processes can be orphaned when the launcher daemon disappears," is fixed on main by 8a5feaa (fix(process-launcher): stop stale host children). The fix preserves active host state when the daemon PID is stale but the recorded child PID is still running, so launch stop can signal the host child before marking the record stopped. It also adds a regression test for the stale-daemon/live-host-child case.

[kamilio]

All reported findings are resolved, including stale launcher-child cleanup (8a5feaa4) and the follow-up runtime/security fixes on main. The complete suite passed (12,603 tests), and the changes shipped in poe-code@3.0.256 via successful release run 27441292197. Closing as released.