What happened?

In the standalone (SEA / Single Executable Application) Windows build of gemini, any call to child_process.fork(modulePath, args) made by application code or by a transitive dependency starts a brand-new gemini session in a child process instead of executing the requested helper script.

The most visible victim is @lydell/node-pty's WindowsPtyAgent._getConsoleProcessList() which is invoked from WindowsPtyAgent.kill() (and therefore from WindowsTerminal.destroy() / .kill()). It runs:

// node_modules/@lydell/node-pty/windowsPtyAgent.js
var agent = child_process.fork(
  path.join(__dirname, 'conpty_console_list_agent'),
  [_this._innerPid.toString()],
);

In the SEA build, process.execPath is gemini.exe itself, so fork() ends up running gemini.exe <conpty_console_list_agent> <pid> instead of node <conpty_console_list_agent> <pid>. The result:

1. A second gemini session starts (full SEA bootstrap, runtime extraction, parent-runner + child-runner spawn).
2. The forked-second-session inherits the original process's environment, so it picks up GEMINI_DEBUG_LOG_FILE and writes interleaved logs into the same file.
3. It is launched with no CLI flags from the original invocation, so --yolo / approval-mode flags are lost — the second session ends up at approvalMode = autoEdit (or whatever the user's default is), even though the user had launched the first session with --yolo.
4. node-pty's parent-side timeout (5 s) eventually fires, kills the spawned process, and resolves with [shellPid]. The expected { consoleProcessList: [...] } IPC message never arrives, so console-handle reaping for the dead PTY does not happen.
5. On Windows Terminal this can also surface a duplicate UI flicker / restart-looking artifact when run_shell_command is used.

What did you expect to happen?

fork()-based helper modules — including @lydell/node-pty's conpty_console_list_agent.js — should execute their actual JavaScript helper, send their IPC reply, and exit. They should never trigger a second full gemini session.

Reproduction (no Gemini session needed — works against any SEA gemini.exe)

The integration test below mirrors what node-pty.windowsPtyAgent._getConsoleProcessList() does, and prints PASS/FAIL deterministically:

// sea-fork-repro.cjs
// Usage:  node sea-fork-repro.cjs <path-to-gemini.exe>
const { fork } = require('node:child_process');
const path = require('node:path');
const fs = require('node:fs');
const os = require('node:os');

const TIMEOUT_MS = 15_000;
const binaryPath = process.argv[2];
if (!binaryPath || !fs.existsSync(binaryPath)) {
  console.error('Usage: node sea-fork-repro.cjs <path-to-binary>');
  process.exit(2);
}

const tmpDir = fs.mkdtempSync(path.join(os.tmpdir(), 'sea-fork-test-'));
const helperPath = path.join(tmpDir, 'fake_console_list_agent.js');
fs.writeFileSync(
  helperPath,
  `const shellPid = parseInt(process.argv[2], 10);
process.send({ status: 'ok', receivedShellPid: shellPid, runtimePid: process.pid });
process.exit(0);
`,
);

const startedAt = Date.now();
const child = fork(helperPath, ['129984'], {
  execPath: binaryPath,
  stdio: ['ignore', 'pipe', 'pipe', 'ipc'],
});

let messageReceived = null;
let exitInfo = null;
let stderrBuf = '';
child.stderr?.on('data', (d) => (stderrBuf += d.toString()));

let finished = false;
function finish() {
  if (finished) return;
  finished = true;
  const elapsedMs = Date.now() - startedAt;
  console.log('elapsed:', elapsedMs, 'ms');
  console.log('message:', JSON.stringify(messageReceived));
  console.log('exit:   ', JSON.stringify(exitInfo));
  if (stderrBuf) console.log('child-stderr:', stderrBuf.slice(0, 300));
  if (!child.killed && exitInfo === null) try { child.kill('SIGKILL'); } catch {}
  try { fs.unlinkSync(helperPath); fs.rmdirSync(tmpDir); } catch {}
  const ok = messageReceived && messageReceived.status === 'ok' && messageReceived.receivedShellPid === 129984;
  console.log(ok ? 'PASS' : 'FAIL — second gemini session spawned instead of helper');
  process.exit(ok ? 0 : 1);
}
child.on('message', (m) => { messageReceived = m; setImmediate(finish); });
child.on('exit', (c, s) => { exitInfo = { code: c, signal: s }; setTimeout(finish, 100); });
setTimeout(finish, TIMEOUT_MS);

Run: node sea-fork-repro.cjs path\to\gemini.exe

Observed result on a SEA Windows build:

elapsed: 15007 ms
message: null
exit:    null
child-stderr: Warning: True color (24-bit) support not detected. ...
              Ripgrep is not available. Falling back to GrepTool.
FAIL — second gemini session spawned instead of helper

The child-stderr lines come from the second gemini session that was started inside the forked child.

Expected result (after fix):

elapsed: 29 ms
message: {"status":"ok","receivedShellPid":129984,"runtimePid":...}
exit:    null
PASS

Root cause

child_process.fork(modulePath, args, opts) defaults opts.execPath to process.execPath. In a SEA build that is the gemini binary itself, so the spawned child runs sea-launch.cjs (and the bundled gemini.mjs) instead of executing the requested .js script.

The same dynamic affects any other downstream helper that uses child_process.fork() from inside the SEA, not just @lydell/node-pty.

Proposed fix

At the very top of sea/sea-launch.cjs's main():

• detect that we are a forked child (typeof process.send === 'function'),
• find the first .js script in process.argv that is not the binary itself,
• normalize argv to the shape a regular Node.js fork would deliver ([binary, script, ...args]) so the helper's existing process.argv[2] reads continue to work,
• load it via Module.createRequire(scriptPath) (the SEA's built-in require() only resolves built-in modules),
• never fall through to gemini's startup path on failure — silently return so the parent's IPC timeout can recover.

A working implementation is in fix/sea-fork-execpath along with the integration test above (committed as sea/sea-launch.fork.integration.test.cjs). PR is incoming.

Client information

• Platform: Windows 11 (10.0.26200)
• Distribution: SEA standalone binary (gemini.exe)
• Gemini CLI version: reproduced on 0.41 / 0.42 builds; the affected code path (sea/sea-launch.cjs and @lydell/node-pty 1.1.0) is unchanged on main as of f52b9b097.
• Node.js version (used to build the SEA): v22.11.0

Login information

N/A — bug is independent of authentication; reproduces with no Gemini session at all (see standalone repro above).

Anything else we need to know?

The bug only manifests in the SEA distribution (gemini.exe). When gemini is invoked via npm install -g @google/gemini-cli so that process.execPath is the real node binary, fork() works correctly and the bug does not appear — which is likely why this has not been widely reported despite the affected code being on main.