Variable name no longer reflects full purpose

suppressDoctorStdout is now used to gate two distinct effects: suppressing doctor output and routing all logs to stderr for clean JSON output. The name only describes one of those effects, which may confuse future readers maintaining this code.

Consider renaming to something that captures the full intent, e.g. isJsonMode:

And update the downstream spread on line 155 accordingly:

      ...(isJsonMode ? { suppressDoctorStdout: true } : {}),

This is a comment left during a code review.
Path: src/cli/program/preaction.ts
Line: 147-150

Comment:
**Variable name no longer reflects full purpose**

`suppressDoctorStdout` is now used to gate two distinct effects: suppressing doctor output *and* routing all logs to stderr for clean JSON output. The name only describes one of those effects, which may confuse future readers maintaining this code.

Consider renaming to something that captures the full intent, e.g. `isJsonMode`:

```suggestion
    const isJsonMode = isJsonOutputMode(commandPath, argv);
    if (isJsonMode) {
      routeLogsToStderr();
    }
```

And update the downstream spread on line 155 accordingly:
```
      ...(isJsonMode ? { suppressDoctorStdout: true } : {}),
```

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

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Avoid redirecting JSON command payloads to stderr

Calling routeLogsToStderr() for every --json invocation flips loggingState.forceConsoleToStderr, so all subsequent console.log writes go to stderr (src/logging/console.ts), not just startup/plugin noise. Many JSON command handlers emit their actual machine-readable payload through runtime.log(...) (for example channelsListCommand uses runtime.log(JSON.stringify(...)) in src/commands/channels/list.ts), and runtime.log delegates to console.log (src/runtime.ts). As a result, non-routed JSON commands like channels ... --json will produce empty stdout and break pipelines expecting JSON on stdout.

Useful? React with 👍 / 👎.

Restore stdout routing in a finally block

When --json is active, routeLogsToStderr() is set before plugin loading, but restoreLogsToStdout() only runs on the success path. If ensurePluginRegistryLoaded throws (for example, a broken plugin manifest), loggingState.forceConsoleToStderr stays enabled for the rest of the process, so later runtime.log(...)/console.log(...) output from in-process callers (tests or embedded CLI invocations) is redirected to stderr and no longer appears on stdout as expected. Wrap the plugin-load section in try/finally so restoration is guaranteed.

Useful? React with 👍 / 👎.