fix(unix): don't rewrite app.asar.unpacked paths a second time

[arthur791004]

Summary

Fixes #923.

src/unixTerminal.ts#L19-L20 does:

helperPath = helperPath.replace('app.asar', 'app.asar.unpacked');
helperPath = helperPath.replace('node_modules.asar', 'node_modules.asar.unpacked');

String.prototype.replace with a string argument matches the first occurrence. When the resolved `helperPath` already contains `app.asar.unpacked/…` (e.g. a caller of node-pty that itself lives inside `app.asar.unpacked`, bypassing Electron's asar shim — see #923 for the concrete repro), the substring `app.asar` matches the prefix of `app.asar.unpacked` and we produce a bogus `…/app.asar.unpacked.unpacked/…` path. `posix_spawn` then fails with `ENOENT` and node-pty surfaces the misleading `posix_spawnp failed.`.

This PR guards each rewrite so it only fires when the unpacked variant isn't already present.

Test plan

• Existing unix-terminal tests still pass (`npm test` → 17/17).
• Manual repro on macOS arm64 from the linked issue's setup: before this patch `pty.spawn` throws `posix_spawnp failed.`; after this patch it spawns normally.

[fei (feiiiiii5)]

Hi — we hit this exact bug in a packaged Electron app on macOS 26 and verified your fix end-to-end. Sharing the evidence and a suggestion:

Reproduction (real runtime): loading node-pty 1.1.0 from an asar layout where it lives under app.asar.unpacked (the standard layout for native modules), every PTY spawn fails with posix_spawnp failed. even for /usr/bin/true. Captured helperPath passed to the native fork: .../app.asar.unpacked.unpacked/node_modules/node-pty/build/Release/spawn-helper. Plain child_process.spawn works, and a byte-level replication of the native spawn sequence with the correct helper path succeeds — confirming the failure is purely the rewritten helper path.

Your patch works: with the guarded rewrite applied, a real /bin/bash PTY spawn succeeds in the same runtime.

Suggestion — this needs tests: the inline rewrite is untestable as written. I've opened #953 which extracts resolveSpawnHelperPath() into a pure function and adds 4 regression tests (RED before the guard: the two "already-unpacked" cases produce app.asar.unpacked.unpacked; GREEN after; full macOS suite 28 passing, eslint clean). Happy to fold those tests into this PR instead if you'd prefer that shape, or rebase #953 on top of this one.

[arthur791004]

Thanks for the verification and for adding the tests — that's a good improvement over what I had here. I'm fine either way 🙂

[fei (feiiiiii5)]

Thanks! Happy to defer to whichever variant is easier to maintain upstream — glad the tests are useful either way.

[fine (fine405)]

Downstream confirmation from OpenAI Codex Desktop: this exact path-rewrite failure is present in build 26.825.51511 on macOS and is tracked at openai/codex#41439.

In the shipped bundle:

• The real helper exists at .../app.asar.unpacked/node_modules/node-pty/build/Release/spawn-helper.
• The current unconditional replacement produces .../app.asar.unpacked.unpacked/node_modules/node-pty/build/Release/spawn-helper.
• The rewritten path does not exist, and the integrated terminal never attaches while backend shell execution remains available.

The Xcode license and first-launch setup are already complete in this reproduction, so that reported workaround is not applicable. The guard in this PR directly addresses the observed bundled path. Linking the downstream report here to help with impact/priority; no private paths or logs are included.