Greptile Summary

This PR fixes a bug (#52032) where plugin-loading logs and other subsystem output would corrupt JSON on stdout when --json mode was used with commands like agents, channels, message, configure, or directory. The fix is minimal and correctly targeted: routeLogsToStderr() is called early in the preAction hook — before any banner emission, config guard, or plugin registry loading — ensuring loggingState.forceConsoleToStderr is set before any code that could emit to stdout.

Key observations:

• The call is correctly placed before emitCliBanner, ensureConfigReady, and ensurePluginRegistryLoaded, so all three are covered by the redirect.
• isJsonOutputMode is called twice (line 127 for the new redirect, line 150 for suppressDoctorStdout) — this is harmless since the function is trivially cheap, but could be extracted to a local variable for clarity in a follow-up.
• The regression test covers all three important cases: a real JSON-output command, the config set --json parse-only exception, and a non-JSON invocation.
• routeLogsToStderr() is idempotent (just sets a flag), so duplicate calls are safe.

Confidence Score: 5/5

• This PR is safe to merge — the change is minimal, well-tested, and correctly placed within the existing hook lifecycle.
• The fix is a one-liner connecting two already-present, already-tested utilities. The test coverage is solid (3 distinct scenarios), no existing tests are broken, and the implementation is idempotent. The only non-blocking observation is that isJsonOutputMode is evaluated twice per invocation, which is trivially cheap and does not affect correctness.
• No files require special attention.

_{Reviews (1): Last reviewed commit: "fix(cli): route logs to stderr in --json..." | Re-trigger Greptile}

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

1. 🔵 Potential CPU denial-of-service from JSON.parse on every console line in --json log-routing

Description

enableConsoleCapture() now calls isJsonPayload(trimmed) while routing console output in --json mode:

• Input: any console.* output (including plugin output and potentially echoed/untrusted data)
• Hot path: forward() runs for every console line
• Issue: isJsonPayload() performs JSON.parse(trimmed) inside a try/catch. For large strings (or many strings starting with {/[), this adds unbounded CPU work; for invalid JSON it also throws repeatedly (exception path is relatively expensive).
• Amplifier: when timestamp prefixing is enabled, isJsonPayload(trimmed) may be evaluated multiple times per line (e.g., for timestamp decision and for stderr routing).

Vulnerable code:

if (loggingState.forceConsoleToStderr && !isJsonPayload(trimmed)) {
  ​// ...
}

function isJsonPayload(value: string): boolean {
  const trimmed = value.trim();
  if (!trimmed.startsWith("{") && !trimmed.startsWith("[")) return false;
  try {
    JSON.parse(trimmed);
    return true;
  } catch {
    return false;
  }
}

This can be used to degrade CLI responsiveness by emitting many large JSON-like lines while --json mode is active (e.g., via plugins or verbose libraries).

Recommendation

Reduce per-line overhead by avoiding (or bounding) JSON parsing in the console hot-path.

Suggested mitigations (can be combined):

1. Cache the detection result per line so it isn't recomputed multiple times:

const isJson = loggingState.forceConsoleToStderr || loggingState.consoleTimestampPrefix
  ? isJsonPayload(trimmed)
  : false;

2. Add a size limit before attempting JSON.parse:

const MAX_JSON_DETECT = 10_000;
if (trimmed.length > MAX_JSON_DETECT) return false;

3. Prefer an explicit structured-output channel (bypass console capture) for command JSON output, e.g. write payloads with process.stdout.write() from a dedicated output function, or prefix command-output lines with a sentinel (so routing does not require parsing).

Example bounded detector:

function isJsonPayload(value: string): boolean {
  const trimmed = value.trim();
  if (trimmed.length > 10_000) return false;
  const first = trimmed[0];
  const last = trimmed[trimmed.length - 1];
  if (!((first === '{' && last === '}') || (first === '[' && last === ']'))) return false;
  try { JSON.parse(trimmed); return true; } catch { return false; }
}

Analyzed PR: #52465 at commit 99e31c2

_{Last updated on: 2026-03-22T23:29:28Z}

Re: Aisle security finding (CWE-74 — JSON output contamination)

This is a valid observation about the broader runtime.log surface, but it's out of scope for this PR and pre-existing behavior — not a regression introduced here.

What this PR does: The fix ensures that console.log() calls from plugin loading, banner emission, and config guards are routed to stderr when --json is active. The runtime.log() stdout bypass (writing directly to process.stdout when forceConsoleToStderr && consolePatched) is intentional — it's specifically how JSON-producing commands deliver their payload to stdout while diagnostic logs go to stderr.

Why the Aisle concern doesn't apply here:

• Commands that produce JSON output (e.g. agents list --json, channels list --json) use runtime.log(JSON.stringify(...)) to write the payload. This must go to stdout for | jq pipelines to work.
• The runtime.log → stdout path is the designed output channel; the Codex reviewer confirmed this is the correct behavior.
• The [secrets] diagnostic strings Aisle references are emitted via console.log, which this PR now correctly redirects to stderr in --json mode.

Follow-up opportunity: Aisle's suggestion to split runtime.log vs runtime.json is a reasonable future improvement (clearer API contract), but orthogonal to the bug fix here. Could be tracked as a separate enhancement.

Landed via temp rebase onto main.

• Gate: pnpm check; pnpm build; pnpm check:docs; OPENCLAW_TEST_PROFILE=low OPENCLAW_TEST_SERIAL_GATEWAY=1 pnpm test
• Land commit: 99e31c2
• Merge commit: 81b498b

Thanks @cgdusek!