SEA + cluster.fork on Windows prepends executable path into worker process.argv (breaks argv parsing)

Version

v24.15.0

Platform

Microsoft Windows NT 10.0.26200.0 x64

Subsystem

single executable applications (SEA), cluster.fork

What steps will reproduce the bug?

Minimal reproduction idea

1. Build a SEA executable whose entry:
   • Prints process.pid, role, process.execPath, and process.argv.slice(2)
   • If primary: cluster.fork() one worker
   • If worker: print argv then exit
2. Run executable with user args, for example:
   app.exe command --flag value
3. Compare primary vs worker argv slice(2).

Primary shows:
["foo","bar"]

Worker shows:
["X:\\...\\app.exe","foo","bar"]

Node.js versions:

• v24.15.0 (reproducible)
• v22.16.0 (reproducible)
• Historically observed since Node 20 era in our project

How often does it reproduce? Is there a required condition?

100% reproducible under these conditions: (1) the application is built as a SEA executable, (2) the primary process uses cluster.fork() to spawn workers, (3) tested on Windows (Linux not verified). Running the same logic with plain node script.mjs does not reproduce the issue — the extra token only appears in SEA-built worker processes.

What is the expected behavior? Why is that the expected behavior?

Observed pattern:

• Primary process process.argv.slice(2):
  ["command","--flag","value"]
• Worker process process.argv.slice(2):
  ["X:\\path\\to\\app.exe","command","--flag","value"]

Expected behavior

Worker processes in SEA mode should see the same user command arguments as primary for process.argv.slice(2), without an injected executable path token.

What do you see instead?

Actual behavior

Worker process argv includes an extra executable path token before actual user arguments.

Additional information

Control test

Running equivalent script without SEA (node script.mjs foo bar) does not show this divergence.

Impact

• Breaks multi-process startup paths in production for SEA apps using argv-based command routing.
• Particularly problematic when a process model uses cluster workers that execute the same CLI entrypoint.

Current workaround

Application-side argv normalization — filter any token in process.argv.slice(2) that equals process.execPath before handing off to the command parser:

import path from 'node:path';

function normalizePathname(p) {
  return path.resolve(p).toLowerCase();
}

function isSelfExecutableArg(arg) {
  if (typeof arg !== 'string' || arg.trim() === '' || arg.startsWith('-')) {
    return false;
  }
  return normalizePathname(arg) === normalizePathname(process.execPath);
}

function normalizeArgv(rawArgv) {
  return rawArgv.filter(arg => !isSelfExecutableArg(arg));
}

// Usage
const argv = normalizeArgv(process.argv.slice(2));

Key points:

• Case-insensitive path comparison is required on Windows (path.resolve + .toLowerCase()).
• The filter must skip tokens starting with - to avoid accidentally dropping flags that happen to match.
• The injected token can appear anywhere in slice(2), not just at index 0, so a .filter over the full array is safer than removing index 0 unconditionally.

This avoids the crash but seems like a workaround for runtime behavior that may be unintended.

Additional notes

If needed, I can provide a complete minimal repro repository.

Signed-off-by

GitHub Copilot

Beginne damit, die in der Issue beschriebene SEA-Executable zu erstellen, und vergleiche process.argv.slice(2) im primary und im cluster.fork()-Worker unter Windows. Verfolge den SEA-Worker-Startup-Pfad, der process.argv erstellt; abgeschlossen ist die Untersuchung, wenn der Worker die Benutzerargumente des primary ohne einen injizierten Executable-Pfad beibehält und der Nicht-SEA-Kontrollfall weiterhin erfolgreich ist.