Repository navigation
Windows: backend segfaults in embedded @parcel/watcher (2.5.1), killing all in-flight sessions #56236
Description
On Windows the v2 server (2.0.29, Bun 1.4.2) crashed after ~18.7 h uptime:
panic(thread 71472): Segmentation fault at address 0xFD8
oh no: Bun has crashed. This indicates a bug in Bun, not your code.
RSS: 2.15 GB | Peak: 2.78 GB
Every crash frame is in the embedded native addon built from parcel-bundler/watcher (watcher.pdb, binding.cc, ReadDirectoryChangesW), on a non-main thread. The desktop host restarted the server (periodic-process-exited, exitCode 3) — and every running session's turn was lost (6 busy sessions at the time). This is the first crash of its kind in ~5 weeks of logs (since 2026-09-10).
This matches parcel-bundler/watcher#262 — a Windows use-after-free where unsubscribe() destroys the Subscription while a ReadDirectoryChangesW completion APC is still pending. OpenCode unsubscribes frequently (location idle eviction, config/skill watch reconciliation), which widens the window.
Ask:
- Track gemini "i'm finished" loop #262 and bump
@parcel/watcheronce it is fixed. - Interim consideration: on Windows, avoid unsubscribe→resubscribe cycles of the same path — reuse the subscription and filter in JS.
Not the reload path: separately verified on the same build (controlled repro, mock LLM, config writes mid-turn) that in-flight turns survive config reloads (agent edit + plugin-generation change) and pick up the new config on their next turn — only the process crash interrupts turns.
Activity
opencode-agent commentedon Oct 16, 2026
Thanks for the careful write-up. Tracing the crash to parcel-bundler/watcher#262 is especially useful.
I think this is a duplicate of #47505. That issue is the same crash: on Windows, the embedded Bun 1.4.2 panics inside the bundled
@parcel/watcheraddon while watch subscriptions are being stopped and restarted. The server exits with code 3, gets restarted, and the active sessions are lost. What triggers the churn varies between reports (bulk skill writes, config reloads, and here idle eviction and watch reconciliation), but the crash is the same.Possible duplicates and related issues, ordered from most to least likely:
@parcel/watcherwhile subscriptions are repeatedly stopped and restarted; the service exits and sessions are lost.binding.cc/watcher.pdb/ReadDirectoryChangesWframes; already closed as a duplicate of core: global skill update terminates shared service on Windows #47505.OPENCODE_DISABLE_FILEWATCHER=1was confirmed to avoid it.servesegfaults after long uptime on Bun 1.4.2, with what look like the same addon frames.It would help to post your upstream analysis (parcel-bundler/watcher#262) and your two suggestions (update
@parcel/watcheronce #262 is fixed; on Windows, reuse the subscription for a path instead of unsubscribing and resubscribing) on #47505, so everything is in one place. Until this is fixed, settingOPENCODE_DISABLE_FILEWATCHER=1avoids the crash, but OpenCode will then no longer notice file changes on its own.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
mradwankhalil commentedon Oct 16, 2026
Thanks — the duplicate analysis is convincing and the related list is helpful. Two additions from our side (both going up on #47505 as you suggested):
No objection to closing this as a duplicate — we'll track #47505.
opencode-agent commentedon Oct 16, 2026
Thanks for confirming, and for moving the crash frames, the parcel-bundler/watcher#262 mapping and both suggestions to #47505. That keeps everything in one place.
Thanks also for checking that in-flight turns survive config reloads. That rules out the reload path as the trigger in your case. The long uptime and high RSS (~18.7 h, 2.15 GB) may well connect to #53688, so it could help to mention that on #47505 too, if you haven't already.
The bot will close this issue as a duplicate of #47505 as planned. Please follow that issue for updates.
opencode-agent commentedon Oct 17, 2026
Closing this as a duplicate of #47505, as you agreed. Thanks for posting the crash frames, the parcel-bundler/watcher#262 mapping and your two suggestions there. Updates on the Windows
@parcel/watchercrash will be on #47505; #53688 tracks the long-uptime Bun segfault. If this turns out to be a different problem, reply here and we'll take another look.mradwankhalil commentedon Oct 23, 2026
Thanks for consolidating the crash report. Understood that #47505 is the Windows watcher tracking issue and #53688 is the related long-uptime Bun crash report; this issue remains a duplicate, not evidence of a separate newly reproduced defect.