fix(core): keep a refused inotify instance from wedging the process

[Nowaker]

Issue for this PR

Closes #16610

Same deadlock as the still-open #37111, but this only fixes one of its two triggers - see the end of the description.

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

You open opencode in a git repo, type a prompt, press Enter - and nothing happens, forever. No error, no toast, nothing in the log, and Esc-Esc won't cancel it. Menus and the model picker still respond, so it doesn't look broken, it looks like the model is thinking. Restarting doesn't help and a fresh session does the same. #16610 hit this a few releases back as a blank screen at startup; today the UI paints fine and the prompt simply never starts a turn.

The trigger is the machine being out of inotify instances. fs.inotify.max_user_instances is a per-uid ceiling, 1024 by default, shared with every other program you run, and raising it needs root. On the machine I found this on, 954 of the 1024 were held by a herd of orphaned KDE kbuildsycoca6 processes - nothing to do with opencode, but opencode is what broke.

Under that pressure inotify_init1 fails inside @parcel/watcher's subscribe(), which builds its shared backend in a synchronous N-API constructor on the calling thread - for us the JS main thread. InotifyBackend::start() throws before notifyStarted(), and Backend::handleError() only notifies watchers that are already registered, so Backend::run() waits on mStartedSignal and never returns. That parks the event loop rather than one fiber, which is why the Effect.timeout(SUBSCRIBE_TIMEOUT_MS) and Effect.catchCause already wrapped around the subscription never fired and nothing reached the log: once the main thread stops returning to the loop, no timer, fiber or signal handler runs again. Only directories under version control are affected, because that is the only branch that reaches subscribe().

The fix is to ask the kernel for one inotify instance, hand it straight back, and call subscribe() only if that worked. The probe and the call sit in one synchronous thunk with nothing in between, so the window where another process takes the last instance is one expression wide. That window is not closed and I'm not claiming otherwise - only fixing @parcel/watcher, or owning the watcher in a killable subprocess, removes the race. What goes away is the permanent silent wedge: a refusal now logs watcher unavailable, continuing without it with the errno, and the session continues without file watching. EMFILE doesn't say whether it was the per-process descriptor limit or the per-uid inotify ceiling, so the errno is logged as-is rather than interpreted. The probe needs bun:ffi, so it is imported only on the inotify branch and only if that import succeeds; a runtime without it keeps the current behaviour instead of silently losing file watching.

What this does not fix: #37111's other trigger, several concurrent subscribes deadlocking while instances are still available. The probe succeeds there and the deadlock still happens.

How did you verify your code works?

Three levels, each under real inotify exhaustion on Linux against the real @parcel/watcher-linux-x64-glibc: the native boundary, a whole turn from source, and a whole turn in a compiled binary.

1. Native boundary. Holding inotify instances open until inotify_init1 returned EMFILE:

1. probe, no pressure      -> undefined            (an instance is obtainable)
   pressure: 841 instances held, stopped on errno=24 EMFILE
2. probe under pressure    -> {"errno":24,"code":"EMFILE"}
3. subscribe() UNGUARDED   -> printed "calling subscribe()", never reached the next line
                              killed at 20s, exit 137
4. subscribe() GUARDED     -> logged the warning, exit 0, 0s
5. probe after release     -> undefined

Step 3 is the bug in two lines: the statement after subscribe() never executes.

2. Whole turn, from source. Throwaway Ubuntu 24.04 VM (glibc 2.39, max_user_instances 128, 124 held until EMFILE). bun run ./src/index.ts run --pure 'say ok' in a fresh git repo, against a local OpenAI-compatible mock so a turn can complete without credentials. Same host, same pressure, same command; the only variable is this patch. Two runs each way, both reproduced:

Tree	Exit	Elapsed	Model replied	Watcher log
this PR	0	7s / 8s	yes	WARN watcher unavailable, continuing without it ... backend=inotify errno=24 code=EMFILE
dev unpatched	137 (SIGKILL)	120s, never returned	no	INFO watcher backend, then silence

3. Whole turn, compiled. Running from source does not cover bun build --compile, and a failure there would be invisible: if the probe's bun:ffi import could not load, that failure is swallowed by design, leaving no probe and no message. Throwaway Arch VM (kernel 7.2.3, glibc 2.44, max_user_instances 1024, 1020 held until EMFILE). Arch packages opencode, so opencode-bin supplies a binary built by the distro package maintainer, and script/build.ts --single supplies patched and unpatched binaries built identically to each other:

Binary	Exit	Model replied	Watcher log
packaged opencode-bin 1.18.30	137 at 120s	no	INFO watcher backend, then silence
self-compiled, this PR	0 in 5s	yes	WARN watcher unavailable ... errno=24 code=EMFILE
self-compiled, unpatched	137 at 120s	no	INFO watcher backend, then silence

Unpressured, all three complete the turn normally. So the defect is present in a released binary, the fix works inside bun build --compile output, and the difference is this patch rather than the build method - the last two binaries came from the same command on the same host minutes apart.

In every wedged run above, the last log line is project copy refresh started, which is also the last line produced on the machine where this was originally found - so these reproduce the original failure rather than merely resembling it.

Reproducing it yourself needs no root, because the ceiling is per-uid: open inotify instances as your own user until inotify_init1 returns EMFILE, then run opencode in any git directory. Before this patch the turn never starts; after it you get the warning and a working session with no file watching.

Tests and gates. packages/core/test/filesystem/watcher-preflight.test.ts is new, and fails with the preflight removed because the watcher then subscribes to both the root and .git and logs no warning. bun test test/filesystem in packages/core is 38 pass on macOS; on Linux watcher.test.ts plus the new watcher-preflight.test.ts are 8 pass, which is the first time the six pre-existing watcher tests have run against the real inotify backend rather than macOS fs-events. The repo's pre-push turbo typecheck is 30/30.

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR