Best possible solution:

Land one canonical maintainer-owned fix for the linked gateway respawn crash and close duplicate fix PRs that do not add unique runtime behavior.

Do we have a high-confidence way to reproduce the issue?

Yes. Current main lacks the child error listener in the detached gateway respawn path, and a direct Node v24.18.0 child_process probe shows the parent exits on an unhandled child error without that listener.

Is this the best way to solve the issue?

No, not as a separate landing branch. The code change is correct, but the best path is the open maintainer-labeled canonical PR that carries the same runtime fix with stronger ordering coverage.

Security review:

Security review cleared: The diff only adds a no-op ChildProcess error listener and unit-test updates; it does not broaden secrets, dependency, workflow, or package execution surfaces.

AGENTS.md: found and applied where relevant.

What I checked:

• Current main still has the underlying bug: On current main, spawnDetachedGatewayProcess calls spawn with detached stdio and immediately calls child.unref() without a child error listener, so the linked crash report is a valid bug but not yet fixed on main. (src/infra/process-respawn.ts:51, 24330a82b44a)
• This PR applies the expected runtime mitigation: The PR head adds child.on("error", () => {}) before child.unref() and adds a focused test that checks listener registration and no-throw handler behavior. (src/infra/process-respawn.ts:56, 26a20695902e)
• Canonical maintainer-labeled PR covers the same fix: fix(infra): handle detached respawn child errors #101489 is open, mergeable, maintainer-labeled, and carries the same production line while using a shared mock child helper and asserting the listener is registered before unref. (src/infra/process-respawn.ts:56, 2d9b586f603c)
• Linked issue and duplicate search: The PR closes the same open crash report at Unhandled error on detached spawned gateway process crashes the Node process #101458, and GitHub search found several same-surface fix PRs for that issue, making one canonical landing path preferable.
• Node child_process contract probe: A Node v24.18.0 probe with a missing executable exited 1 with an unhandled ChildProcess error when no listener was attached, and exited 0 when child.on('error', () => {}) was attached.
• Feature history: git blame ties the current respawn function on main to commit 7b366e1 from the Windows CLI backend work, which is the relevant current-main provenance for routing. (src/infra/process-respawn.ts:41, 7b366e16b0b3)

Likely related people:

• steipete: git blame and live PR metadata tie the current process-respawn implementation to the merged Windows CLI backend work. (role: introduced current respawn path; confidence: high; commits: 7b366e16b0b3; files: src/infra/process-respawn.ts, src/infra/process-respawn.test.ts, src/cli/gateway-cli/lifecycle.runtime.ts)
• giodl73-repo: Authored the merged restart-helper fix that used the same detached child error-listener pattern for update restart script handoff. (role: adjacent sibling-fix contributor; confidence: medium; commits: e224c84c348c; files: src/cli/update-cli/restart-helper.ts, src/cli/update-cli/restart-helper.test.ts)
• momothemage: Authored the open maintainer-labeled PR carrying the same production fix and stronger process-respawn regression coverage. (role: canonical follow-up PR owner; confidence: medium; commits: 2d9b586f603c; files: src/infra/process-respawn.ts, src/infra/process-respawn.test.ts)

Codex review notes: model internal, reasoning high; reviewed against 24330a82b44a.