Repository navigation
Windows segfault: Bun 1.3.9 crash during active multi-tool session (no graceful shutdown) #14204
Closed as not planned
Description
Summary
OpenCode process crashes on Windows with a Bun segmentation fault during an active session that had multiple tool calls in flight.
This appears to be a Bun runtime crash, but it is surfaced through OpenCode and causes abrupt session loss.
Environment
- OpenCode CLI: 1.2.6
- Bundled Bun: 1.3.9 (
cf6cdbbb) - OS: Windows 11 x64
- CPU features:
sse42 avx avx2 avx512
Crash Signature
panic(thread ...): Segmentation fault at address 0xFFFFFFFFFFFFFFF8- Also reported as:
Segmentation fault at address 0xFFFFFFFFFFFFFFFF - Crash report includes:
WebCore::JSBlobConstructor::constructsimdutf ... encode_base64_implWebCore::JSRequestConstructor::calloh no: Bun has crashed. This indicates a bug in Bun, not your code.
What Happened Immediately Before Crash
- OpenCode loaded plugins including
oh-my-opencode. - It auto-updated
oh-my-opencodefrom3.7.3to3.7.4viabun add ... oh-my-opencode@latest. - A new session started.
- The active assistant turn launched multiple tool calls (search/session search/glob/grep/AST-grep + background subagents).
- Process crashed around ~180s elapsed.
Observable Impact
- Server log for that run ends abruptly mid-request (no clean shutdown sequence).
- DB state for the crashed session shows multiple tool parts stuck in
runningstate (10), indicating abrupt termination while tools were still executing.
Why This Is Filed Here
I agree the segfault root cause is likely Bun, but OpenCode is the runtime host here. Useful OpenCode-side mitigations could include:
- Optional safety mode for Windows to force baseline binary / disable risky paths.
- Guardrail for plugin auto-update during active startup/session.
- Recovery marker when process exits while tool states are still
running. - Better crash-handling UX with resumable context and one-click issue export.
Repro (high-level)
- Windows 11 x64, OpenCode 1.2.6 with bundled Bun 1.3.9.
- Enable plugin set including
oh-my-opencode. - Start a session and run a high-concurrency analysis prompt (parallel tool + background agent fan-out).
- After a few minutes, process may segfault with the Bun signature above.
If needed, I can provide additional redacted structured artifacts (session/tool state timeline) without personal paths.
Activity
github-actions commentedon Feb 18, 2026
This issue might be a duplicate of existing issues. Please check:
oh-my-opencodeauto-updating just before the crash, which closely matches this issueIf your issue is already addressed by one of these, please consider closing this one or adding any new details there.
Hona commentedon Feb 18, 2026
can you try fully uninstalling omo?
then reinstalling it?
one user with segfaults reported this was the fix
Hona commentedon Feb 18, 2026
I am now suddently getting segfaults lol... hopefully bun 1.3.10 fixes this
xirain commentedon Feb 25, 2026
not related with version of omo. it's my local folder, change to another folder, can open opencode successfully.
abakumov-v commentedon Feb 25, 2026
I tried to fully re-install opencode + cleaning
./.config/opencodeand./.local/share/folder for my windows user profile's folderthen I re-cloned git repo (thought that it might be a problem after my laptop went turned off accidentially)
nothing helped
I have bun installed on my windows 11 -
1.2.15but got same error about bun 1.3.10 canary ...
Small update - for another repo it works fine - so looks like it's a repo-specific problem
I tried to delete
.opencodefolder in the repo, and error still happensopencode = 1.2.14
abakumov-v commentedon Feb 25, 2026
okay, I found the reason why it's failing only for one repo on my local -
.envfile 😢even though it was added to
.opencodeignore🫤but it worked before...
abakumov-v commentedon Feb 25, 2026
this is also interensting bug - it shows
injecting env (0) from .envright in the input area:abakumov-v commentedon Feb 25, 2026
found this same issue but more detailed - #15015
github-actions commentedon Apr 27, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.