Greptile Summary

This PR fixes plugin init logs (e.g. [plugins] lines) contaminating stdout when the CLI is used in piped scripts like $(openclaw message send ...). The fix is minimal and correct: a single TTY check in runCli() calls the pre-existing routeLogsToStderr() when !process.stdout.isTTY, redirecting all diagnostic log output to stderr while leaving stdout clean for command output. Interactive TTY sessions are entirely unaffected.

Key observations:

• The placement of the TTY check (after enableConsoleCapture() but before any plugin/program imports) ensures all subsequent diagnostic output is captured on the right stream.
• loggingState.forceConsoleToStderr is read lazily by the forward wrapper at call time, so there are no ordering or race-condition concerns.
• When process.stdout.isTTY is undefined (CI, non-interactive environments), !undefined === true triggers the redirect — correct behavior for those contexts.
• The new tests cover the happy path and the negative case. Minor note: the first test calls routeLogsToStderr() before enableConsoleCapture(), which is the reverse of the production call order — functionally safe but worth aligning for fidelity.

Confidence Score: 5/5

• Safe to merge — minimal, targeted fix with correct behavior across all stdout states (TTY, piped, undefined).
• The change is a single conditional call to an already-tested and well-understood helper. No new state is introduced, the fix is idempotent, and the only style concern (test call ordering) does not affect correctness or production behavior.
• No files require special attention.

This is a comment left during a code review.
Path: src/logging/console-capture.test.ts
Line: 136-147

Comment:
**Test call order inverted from production**

The test calls `routeLogsToStderr()` before `enableConsoleCapture()`, but the production code in `run-main.ts` does the opposite — `enableConsoleCapture()` first, then `routeLogsToStderr()`. This works because `loggingState.forceConsoleToStderr` is read lazily inside the `forward` wrapper at call time (not captured at setup time), so both orderings are functionally equivalent. However, aligning the test with the actual production call order would make it a better regression guard.

```suggestion
  it("routes info-level console.log to process.stderr when enabled", () => {
    setLoggerOverride({ level: "info", file: tempLogPath() });
    enableConsoleCapture();
    routeLogsToStderr();
    const stderrWrite = vi.spyOn(process.stderr, "write").mockReturnValue(true);
    const stdoutWrite = vi.spyOn(process.stdout, "write").mockReturnValue(true);
    console.log("[plugins] test message");
    expect(stderrWrite).toHaveBeenCalled();
    const written = String(stderrWrite.mock.calls[0]?.[0] ?? "");
    expect(written).toContain("test message");
    expect(stdoutWrite).not.toHaveBeenCalled();
  });
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: "fix(cli): route diag..."}

Addressed both review comments in the latest push:

@greptile-apps (test call order): Fixed — but went further than just swapping the call order. The original routeLogsToStderr() approach was too broad, so the test was rewritten to match the new implementation.

@chatgpt-codex-connector (version stdout concern): Great catch — this was a real bug. routeLogsToStderr() would have broken openclaw --version | cat (and all runtime.log() data output).

Revised approach: Instead of globally routing all console.log to stderr, the fix is now scoped to writeConsoleLine() in src/logging/subsystem.ts — which only handles subsystem diagnostic logs (like [plugins]). Command data output via runtime.log() / console.log() is unaffected. Additionally, version output in help.ts now uses process.stdout.write() directly since it's data, not a diagnostic log.

To use Codex here, create a Codex account and connect to github.

Excellent revision! The scoped approach is much cleaner:

✅ subsystem.ts:248-251 — TTY check is perfectly placed. Only routes info/debug/trace subsystem logs to stderr when piped, leaving runtime.log() untouched.

✅ help.ts:114-117 — Good catch on the version bug. process.stdout.write() is correct here since version is data output, not a diagnostic.

The new tests properly verify both TTY states. This is a solid, surgical fix that solves the original issue without side effects. Ready to ship.

Closing this as duplicate or superseded after Codex automated review.

Close as superseded. Current main uses the safer scoped stdout-reservation path from merged PR #52449/current startup policy, while #51641's non-TTY subsystem-wide stderr routing is intentionally not present because it was too broad for daemon/container/CI logs.

Best possible solution:

Close #51641 as superseded by merged #52449 and the current scoped JSON/stdout-reservation startup path. Keep stderr routing tied to explicit machine-output modes and plugin-load save/restore; handle any future non-JSON stdout contract gap with a targeted command-level issue or PR.

What I checked:

• Superseding PR context: Provided GitHub context shows fix(cli): route plugin logs to stderr during --json output #52449 was merged and explicitly identified fix(cli): route diagnostic logs to stderr when stdout is piped #51641 as too broad because routing subsystem logs by !process.stdout.isTTY affects daemon/container/CI operational logs; fix(cli): route plugin logs to stderr during --json output #52449 is the canonical merged follow-up for the JSON/plugin-log stdout corruption chain. (c0b472897f88)
• Scoped startup routing: Current main routes console diagnostics to stderr only when the startup policy says stdout is suppressed, rather than for every non-TTY process. (src/cli/command-execution-startup.ts:29, 76cf013df507)
• JSON mode is the policy trigger: resolveCliStartupPolicy() derives suppressDoctorStdout directly from jsonOutputMode, keeping the behavior mode-scoped instead of TTY-scoped. (src/cli/command-startup-policy.ts:41, 76cf013df507)
• Plugin-load save/restore: Plugin registry loading temporarily sets loggingState.forceConsoleToStderr only when requested, then restores the previous value in finally, matching the safer scoped approach described by fix(cli): route plugin logs to stderr during --json output #52449. (src/cli/plugin-registry-loader.ts:18, 76cf013df507)
• Broad PR approach absent on main: writeConsoleLine() still routes only forced stderr/error/fatal to error, warnings to warn, and other levels to log; there is no !process.stdout.isTTY branch from fix(cli): route diagnostic logs to stderr when stdout is piped #51641 on current main. (src/logging/subsystem.ts:252, 76cf013df507)
• Regression coverage for scoped behavior: Tests assert JSON-output startup routes logs to stderr, parse-only config set --json does not, and non-JSON commands do not route logs globally. (src/cli/program/preaction.test.ts:395, 76cf013df507)

So I’m closing this here and keeping the remaining discussion on the canonical linked item.

Codex Review notes: model gpt-5.5, reasoning high; reviewed against 76cf013df507; fix evidence: release 2026.3.22, commit c0b472897f88.