fix: do not use electron argv parsing with ELECTRON_RUN_AS_NODE

[nirmal-shaji]

Summary

Command.parse() mis-parses argv when ELECTRON_RUN_AS_NODE is set (#2603).

When an Electron main process spawns a JS child with ELECTRON_RUN_AS_NODE=1, the child runs as plain Node — the argv layout is Electron script.js [...args], exactly like node script.js [...args], so script.js is the script path, not a user argument. But process.versions.electron is still truthy, so auto-detection picked from: 'electron'; and because process.defaultApp is undefined, the script path was kept as a user argument (argv.slice(1)).

Fix

Only auto-select the electron convention when the process is actually running as an Electron app, i.e. when ELECTRON_RUN_AS_NODE is not set:

if (process.versions?.electron && !process.env.ELECTRON_RUN_AS_NODE) {
  parseOptions.from = 'electron';
}

This is intentionally minimal and only touches auto-detection; passing { from: 'electron' } explicitly is unchanged.

On the fragility

I saw @shadowspawn's note that this heuristic is inherently fragile — we can't know at parse time whether the executable was launched with the env var or it was set afterwards. Agreed. This guard doesn't try to solve that general case; it aligns auto-detection with the documented meaning of ELECTRON_RUN_AS_NODE ("run as a normal Node.js process"), which covers the common case in the report (env var set as part of the spawn). It's a small, spec-consistent improvement over unconditionally trusting process.versions.electron, and explicit from remains available for anything more exotic.

Test

Added a case to tests/command.parse.test.js alongside the existing electron auto-detection test: with process.versions.electron and ELECTRON_RUN_AS_NODE set and argv = 'node script.js user', the script path is excluded and program.args is ['user']. Confirmed it fails before the fix and passes after.

npm test (node --test) green — 1373 passing.

Fixes #2603

[nrps9909]

Reviewed 3ac5c5d01fa91090218b8c4ed10663616cd03825.

Confirmed the reported script-path leak before the change and checked nine parsing cases on this head: unset/empty ELECTRON_RUN_AS_NODE, non-empty 1/0/false, explicit from: 'electron'/'node'/'user', and a supplied argv array. All matched the expected arguments. Using truthiness here also matches Electron's non-empty environment-value check in its macOS entry point; restricting the value to '1' would miss other enabled values.

npm test: 1,373 passed, one skipped. npm run check: types, lint and formatting passed (Node 26.8.1, macOS). I cleared inherited color variables for the full test run: the existing configureOutput tests otherwise fail with my NO_COLOR=1; that also reproduces independently on develop and is outside this change.

No blocking findings in this auto-detection change. The additional parsing probe mocks Electron process metadata, consistent with the existing test file; it is not a real Electron process launch.

[shadowspawn]

To be clear: is this Pull Request entirely AI/LLM generated?

[shadowspawn]

This account opened multiple PR on the same day, the PR shows heavy use of AI, and does not follow the contributing guidelines.

And in addition, giving the person who reported the problem first choice for fixing the problem!