DEP0190 on Node 24: every companion command warns on stderr before its JSON

What happens

On Node 24, any codex-companion.mjs invocation prints a deprecation warning to stderr before its output:

$ node ".../openai-codex/codex/1.0.6/scripts/codex-companion.mjs" setup --json
(node:70392) [DEP0190] DeprecationWarning: Passing args to a child process with shell option true can lead to security vulnerabilities, as the arguments are not escaped, only concatenated.
(Use `node --trace-deprecation ...` to show where the warning was created)
{
  "ready": true,
  ...
}

The JSON itself is correct — the warning is on stderr, and setup reported the plugin healthy (codex-cli 0.152.1, ChatGPT login active).

Where

--trace-deprecation names the call site:

at runCommand      (scripts/lib/process.mjs:5:18)
at binaryAvailable (scripts/lib/process.mjs:39:18)
at buildSetupReport (scripts/codex-companion.mjs:184:22)
at handleSetup     (scripts/codex-companion.mjs:237:29)

scripts/lib/process.mjs:12 defaults the shell option on Windows:

shell: options.shell ?? (process.platform === "win32" ? (process.env.SHELL || true) : false),

so every bare command name spawned with args on Windows — codex --version, node --version, npm --version in binaryAvailable — trips DEP0190. scripts/lib/git.mjs already passes shell: false explicitly and does not.

Why it is worth fixing rather than ignoring

Two reasons beyond noise:

1. It is the warning's actual subject. With shell: true the args are concatenated into a command line rather than escaped. These particular args are literals (--version), so nothing is exploitable today; the pattern is what Node is deprecating, and the same helper is what other call sites reach for.
2. stderr belongs to the caller. These scripts are invoked as subprocesses — by hooks, by slash commands, by other agents. A consumer that merges stderr into stdout (2>&1, or a hook harness that does it for you) hands its JSON parser a (node:NNNN) line and the call fails with nothing in the log to explain it. Structured output is a contract; anything unconditional on the shared stream is part of what the contract delivers.

Possible fixes

• Resolve the binary path and spawn with shell: false (Windows can spawn a .cmd/.exe directly when the path is absolute), or
• keep the shell but pass a single pre-composed command string with no args array, or
• set process.noDeprecation = true in the entry scripts if the shell default is deliberate — cheapest, though it silences the warning rather than the pattern.

Environment

• codex plugin 1.0.6 (openai-codex marketplace), installed at .../cache/openai-codex/codex/1.0.6
• Node v24.14.1, npm 11.11.0, Windows 11 26200
• codex-cli 0.152.1
• Reproduces on every codex-companion.mjs subcommand I ran, setup --json included

Repro

node "<plugin>/scripts/codex-companion.mjs" setup --json
# warning appears on stderr before the JSON
node --trace-deprecation "<plugin>/scripts/codex-companion.mjs" setup --json
# names process.mjs:5 -> binaryAvailable -> buildSetupReport

Start with scripts/lib/process.mjs, especially runCommand and its Windows shell default, then trace binaryAvailable from scripts/codex-companion.mjs and compare the explicit shell handling in scripts/lib/git.mjs. Reproduce setup --json on Node 24 and Windows; done means companion commands emit parseable JSON without the DEP0190 warning on stderr.