fix: make spawn() work when host is an Electron main process

[Copilot]

In an Electron main process, process.execPath is the Electron binary. Spawning the bundled .js CLI with it fails two ways: bare spawn triggers single-instance lock → clean exit → misleading CLI server exited unexpectedly with code 0; with ELECTRON_RUN_AS_NODE=1 alone, process.versions.electron is still set in the child, Commander picks Electron argv parsing, and --headless is misclassified as a positional arg → error: too many arguments.

Changes

• applyElectronSpawnEnv(env, isJsFile) (client.ts) — new @internal helper; when process.versions.electron !== undefined and the CLI is a .js file, injects ELECTRON_RUN_AS_NODE=1 and COPILOT_CLI_RUN_AS_NODE=1 via ??= (caller values are never overwritten). No-ops in all non-Electron hosts.

• getNodeExecPath(override?) — accepts an optional path override; exported @internal for testability.

• CopilotClientOptions.nodeExecPath?: string (types.ts) — escape hatch for Electron apps that bundle a real Node binary, bypassing the env-var injection entirely:

  const client = new CopilotClient({
      nodeExecPath: process.env.MY_APP_NODE_PATH ?? "node",
  });

• startCLIServer() — wired to call applyElectronSpawnEnv before spawn and pass options.nodeExecPath to getNodeExecPath.

• 6 new unit tests covering injection, no-overwrite, non-.js skip, non-Electron no-op, override, and option storage.

• README — new "Electron usage" section documenting both failure modes and both fixes.

• CHANGELOG — [Unreleased] Fixed entry.

[Copilot]

Pull request overview

Fixes a startup failure when the Node.js SDK is hosted inside an Electron main process, where process.execPath points at the Electron binary and spawning the bundled .js CLI either silently exits (single-instance lock) or trips Commander's Electron argv parsing on --headless.

Changes:

• New @internal helper applyElectronSpawnEnv() injects ELECTRON_RUN_AS_NODE=1 and COPILOT_CLI_RUN_AS_NODE=1 (via ??=) for .js CLIs when process.versions.electron is defined, and getNodeExecPath() now accepts an optional override.
• New public CopilotClientOptions.nodeExecPath escape hatch for apps that bundle a real Node binary; wired through to the .js spawn branch in startCLIServer().
• Documentation (README "Electron Usage" section, CHANGELOG Unreleased entry) and 6 unit tests covering injection, no-overwrite, non-.js, non-Electron, override, and option storage.

Show a summary per file

File	Description
nodejs/src/client.ts	Adds applyElectronSpawnEnv, extends getNodeExecPath with override, stores nodeExecPath option, and uses both in the .js spawn branch.
nodejs/src/types.ts	Adds nodeExecPath?: string to CopilotClientOptions with JSDoc explaining the Electron use case.
nodejs/test/client.test.ts	New Electron spawn environment describe block exercising helper behavior and option storage.
nodejs/README.md	New "Electron Usage" section documenting failure modes, automatic fix, and nodeExecPath escape hatch.
CHANGELOG.md	Adds an [Unreleased] entry describing the fix and new option.

Copilot's findings

• Files reviewed: 5/5 changed files
• Comments generated: 1

[Copilot]

Addressed in 9480efeb: removed the manual [Unreleased] CHANGELOG entry so release notes remain generator-managed.

[SteveSandersonMS]

@friggeri Just reviewing the backlog and realized this is still waiting.

Is this something you're still keen to merge? I'm asking because most likely for your own app you have a relatively clean workaround (e.g., setting the CLI path arg to point to whatever node binary you want to use and dist-cli/index.js as its arg, and you could manually pass the env vars like ELECTRON_RUN_AS_NODE).

My only hesitancy in merging is that relatively soon there won't be a Node dependency at all anyway, so having any public APIs that are specifically framed in terms of Node will become legacy. Maybe if you don't need this in the short term (because you have workarounds) we would be better off skipping it.