🤖 fix: drop node-pty and the Electron rebuild step, make buildTime reproducible

[ethanndickson]

The Nix build at 60d40394d had two problems: postinstall.sh always failed inside the sandbox (no Electron headers, --ignore-scripts in the FOD) and exit 0 swallowed the failure, and buildTime came from the wall clock so the output was never reproducible.

Whilst looking into the first one, it turned out the rebuild step never did necessary work. #660 moved us to node-pty@1.1.0-beta39 and added @electron/rebuild in the same PR, but beta39 is where node-pty switched from nan to node-addon-api. Node-API is ABI-stable across Node and Electron, so the rebuild was producing a binary functionally identical to the prebuild it overwrote. #664 then added @lydell/node-pty as a fallback on the assumption that its Mac prebuilds weren't built for the Electron ABI; they're Node-API too, and the desktop app has been loading them inside Electron for SSH, Docker and devcontainer terminals since that PR landed. On Linux node-pty has no prebuild at all, so Nix and Docker were already on @lydell for every terminal.

So, we'll just keep @lydell/node-pty. This removes node-pty, @electron/rebuild, scripts/postinstall.sh, make rebuild-native, the two-package loader in ptySpawn.ts, and the XUM_HEADLESS plumbing in the Dockerfile, flake and benchmark setup. The DuckDB rebuild step goes too; @duckdb/node-bindings has no binding.gyp, so it was a no-op. asarUnpack now covers @lydell/** so pty.node, spawn-helper and the conpty files leave the asar. @types/node is pinned at ^24.9.0 because it was previously hoisted from electron and would otherwise fall back to the Node 20 types.

For buildTime, generate-version.sh now uses SOURCE_DATE_EPOCH, falling back to the commit time and then the wall clock (Docker builds have no .git). The flake sets SOURCE_DATE_EPOCH from self.lastModified so About shows the commit date rather than 1980. The "reuse existing buildTime" block from #2915 is gone since the existing cmp -s early exit now gives the same HMR stability. Release builds will show the tagged commit's time rather than when CI ran.

I verified the untouched @lydell Linux prebuild from the Nix output loads and spawns a shell under Electron 40.10.0 and 43.6.0 via ELECTRON_RUN_AS_NODE, and nix build .#xum --rebuild passes. The one path that actually changes behaviour is Local terminals on macOS/Windows desktop, which move from one Node-API pty prebuild to another of the same fork. I haven't run make dist-win, so Windows desktop is the least exercised path here.

Unrelated: the offlineCache FOD flakes with Fail extracting tarball for "mermaid" in roughly 2 of 3 sandbox runs, with both the old and new lockfile. I dug into it (strace, curl inside the sandbox) and it looks like a bun extraction flake on the largest tarball rather than a network or lockfile issue. Out of scope for now.

---

Generated with xum • Model: anthropic:claude-fable-5-1 • Thinking: xhigh • Cost: $17.46

[ethanndickson]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-21T04:18:28.019014Z	4e4494b	Manual request
🔒 Security Review	✅ Completed 2026-09-21T04:17:25.614718Z	4e4494b	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

🛡️ Codex Security Review · Automatically triggered

Security review completed. No security issues were found in this pull request.

Reviewed commit: 4e4494bb7c

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. You're on a roll.

Reviewed commit: 4e4494bb7c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".