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.