Fix server fallback to direct fd read on /proc/self/fd failure

[rishi-chauhan]

What Changed

On some Linux environments (containers, restricted kernels), /proc/self/fd/<n> exists but cannot be opened, returning ENXIO, EINVAL, or EPERM. Previously this would surface as a hard BootstrapError. Now the server falls back to reading the fd directly, matching the behavior already used on Windows.

Also prefers fs.createReadStream over net.Socket for the direct fd path, as it is better behaved for regular file descriptors.

Why

I tried to launch the app via code on my linux (pop os) machine and was facing an error. Fixed the error and everything looks good now

UI Changes

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

Medium Risk
Medium risk because it changes how bootstrap data is read from inherited file descriptors and adjusts fd/stream ownership (autoClose), which can affect startup behavior and resource lifecycles on Linux.

Overview
Fixes server bootstrap reads in restricted Linux environments by falling back to reading directly from the inherited fd when opening /proc/self/fd/<n> fails with ENXIO/EINVAL/EPERM, instead of throwing a BootstrapError.

Refactors direct-fd handling to prefer fs.createReadStream (with autoClose: true) and only fall back to net.Socket if stream creation fails, and adds a unit test that mocks fs.openSync to force the duplication-failure path and assert the fallback behavior.

^{Written by Cursor Bugbot for commit 286e7c2. This will update automatically on new commits. Configure here.}

Note

Fix server bootstrap to fall back to direct fd read when /proc/self/fd duplication fails

• When opening a platform-specific fd path (e.g. /proc/self/fd/<n>) fails with ENXIO, EINVAL, or EPERM, makeBootstrapInputStream now falls back to reading directly from the inherited fd instead of throwing.
• Adds makeDirectBootstrapStream which prefers NFS.createReadStream with autoClose: true, falling back to a Net.Socket only if stream creation throws.
• Adds isBootstrapFdPathDuplicationError predicate to distinguish recoverable fd-duplication errors from other failures.
• Behavioral Change: platforms without a resolvable fd path now use createReadStream before Net.Socket, reversing the previous preference order.

^{Macroscope summarized 286e7c2.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: cf8d507b-322a-42df-b181-912206a31d68

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[juliusmarminge]

Also prefers fs.createReadStream over net.Socket for the direct fd path, as it is better behaved for regular file descriptors.

@Ivorisnoob iirc you recommended using Net.Socket on the fallback path. Thoughts?

[Ivorisnoob]

Also prefers fs.createReadStream over net.Socket for the direct fd path, as it is better behaved for regular file descriptors.

@Ivorisnoob iirc you recommended using Net.Socket on the fallback path. Thoughts?

one minute let me checkout this

[Ivorisnoob]

Ah right, @juliusmarminge my Net.Socket suggestion was only meant for the Windows pipe case, should've been clearer about that. fs.createReadStream is the better default here since it handles both regular fds and pipes without complaining (unlike Net.Socket which throws ERR_INVALID_FD_TYPE on regular file fds).

The PR overall looks solid to me. The ENXIO/EINVAL/EPERM catch on the /proc/self/fd path is a real fix for restricted Linux environments and the fallback chain makes sense. Nice one 👍