Bun v1.3.13 panic on macOS: NAPI FATAL ERROR napi_create_error and zsh: trace trap opencode #24148

Activity

1. github-actions

   assigned

   rekram1-node

   on Apr 24, 2026
2. github-actions

   added

   coreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)

   perfIndicates a performance issue or need for optimizationIndicates a performance issue or need for optimization

   on Apr 24, 2026
3. github-actions commented on Apr 24, 2026

   

   github-actionsBot

   on Apr 24, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • bun crash on opencode first start #24075: Also reports a Bun v1.3.13 crash on startup (same bundled runtime version, same oh no: Bun has crashed output)

   If this is the same root cause, consider adding your details there instead. If the symptoms differ (e.g. different crash type, different trigger), feel free to keep this issue open with a note explaining the distinction.
4. sukris commented on Apr 24, 2026

   

   sukris

   on Apr 24, 2026

   Author

   More actions

   Additional reproduction detail:

   This appears to be specifically tied to the interrupt/exit path.

   In my environment, the crash is reproducible when exiting opencode with Ctrl + C. It is not primarily a random crash during normal interaction.

   Observed behavior:

   1. Start opencode normally
   2. Use it interactively
   3. Press Ctrl + C to exit
   4. The process panics with:
      • panic: NAPI FATAL ERROR: Error::New napi_create_error
      • oh no: Bun has crashed. This indicates a bug in Bun, not your code.
      • zsh: trace trap opencode

   So this currently looks like a SIGINT / shutdown cleanup crash on macOS zsh rather than a general runtime failure during normal use.
5. sukris commented on Apr 24, 2026

   

   sukris

   on Apr 24, 2026

   Author

   More actions

   Additional narrowing from local verification:

   I tried a small matrix around SIGINT handling to help isolate the trigger.

   What I found:

   • opencode run hello --print-logs + SIGINT did not reproduce the Bun panic in my local test
   • I could not reliably reproduce the same panic with a scripted non-interactive SIGINT harness
   • The strongest signal is still: interactive TUI usage + real terminal Ctrl + C on exit

   So at this point the issue seems more likely to be in the interactive TUI shutdown / signal handling / cleanup path on macOS zsh, rather than a generic SIGINT failure across all modes.

   This may help narrow the search surface to the TUI exit path instead of opencode run or general non-interactive execution.
6. sukris commented on Apr 24, 2026

   

   sukris

   on Apr 24, 2026

   Author

   More actions

   New data point: the crash is not limited to Ctrl + C.

   I can also reproduce it when exiting from inside the TUI with /exit.

   That seems important because it suggests this is not only a SIGINT problem. It may be a broader shutdown / teardown / cleanup-path bug in the interactive TUI on macOS.

   Additional details from the latest crash output:

   • bundled runtime still reports Bun v1.3.13
   • panic is still NAPI FATAL ERROR: Error::New napi_create_error
   • terminal still ends with trace trap opencode
   • this run had been alive for a relatively long session before exit (Elapsed: 627298ms)
   • runtime stats at crash time included roughly RSS: 0.68GB and Peak: 0.98GB

   One more observation: the terminal output looked partially garbled / mixed with prior session content around the time of exit. I am not sure whether that is cause or consequence, but it may indicate the shutdown path is racing with TUI/terminal cleanup.

   So the current best hypothesis is:

   • not just Ctrl + C
   • also reproducible via /exit
   • likely in interactive TUI shutdown / teardown / cleanup
   • possibly involving terminal state restoration and/or N-API-backed cleanup during exit

   Latest Bun report link from this crash:

   https://bun.report/1.3.13/Ma1bf2e2cemxnQz+3/9/D+7w+hDmwyhZ_____mwpwDmrmzD+ohyN+8y1nBu641nB+g5H+hu1nB__A0eNrzcwzwVHBzDHH0UXANCvIPslJwLSrKL7Ky8kstV8hLLMiMTy5KTSxJjU8FCQMASAIPgQ

   👍React with 👍1Reacted by Suknna
7. rhortal commented on Apr 29, 2026

   

   rhortal

   on Apr 29, 2026

   Last edited by rhortal

   More actions

   Happens to me as well. Every time, when I /quit. Only on one laptop, not the other. https://bun.report/1.3.13/Ma1bf2e2cemxHugogC+7w+hDmwyhZ_____mwpwDmrmzD+ohyN+8y1nBu641nB+g5H+hu1nB__A0eNrzcwzwVHBzDHH0UXANCvIPslJwLSrKL7Ky8kstV8hLLMiMTy5KTSxJjU8FCQMASAIPgQ is the latest report.

   Error message:
   Bun v1.3.13 (bf2e2cec) macOS Silicon
   macOS v26.4.1
   CPU: neon fp aes crc32 atomics
   Args: "/opt/homebrew/lib/node_modules/opencode-ai/bin/.opencode" "--user-agent=opencode/1.14.29" "--use-system-ca" "--"
   Features: Bun.stderr(4) Bun.stdin(4) Bun.stdout(4) fetch(6) jsc spawn(15) standalone_executable transpiler_cache(6) workers_spawned workers_terminated napi_module_register(2) process_dlopen(3)
   Builtins: "bun:ffi" "bun:main" "bun:sqlite" "node:assert" "node:async_hooks" "node:buffer" "node:child_process" "node:console" "node:crypto" "node:dns" "node:events" "node:fs" "node:fs/promises" "node:http" "node:https" "node:module" "node:net" "node:os" "node:path" "node:process" "node:querystring" "node:readline" "node:stream" "node:stream/consumers" "node:stream/promises" "node:string_decoder" "node:timers" "node:timers/promises" "node:tls" "node:tty" "node:url" "node:util" "undici" "ws" "node:v8" "node:http2" "node:diagnostics_channel" "node:dgram"
   Elapsed: 8492ms | User: 3470ms | Sys: 423ms
   RSS: 0.72GB | Peak: 0.72GB | Commit: 124.39MB | Faults: 74 | Machine: 34.36GB

   panic: NAPI FATAL ERROR: Error::New napi_create_error
   oh no: Bun has crashed. This indicates a bug in Bun, not your code.
8. thdxr

   removed

   perfIndicates a performance issue or need for optimizationIndicates a performance issue or need for optimization

   coreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)

   on May 3, 2026
9. gretel commented on May 6, 2026

   

   gretel

   on May 6, 2026

   More actions

   happens to me as soon as i run more than one session.
10. Mte90 commented on May 6, 2026

    

    Mte90

    on May 6, 2026

    More actions

    I believe that oven-sh/bun#29464 is the culprit
11. shiyan-salt

    marked Crash: EXC_BREAKPOINT in ONNX Runtime 1.21.0 via Bun N-API on Apple Silicon #26132 as a duplicate of this issue on May 7, 2026
12. shiyan-salt commented on May 7, 2026

    

    shiyan-salt

    on May 7, 2026

    Last edited by shiyan-salt

    More actions

    I ran into this issue when starting a new session and asking a second question, which must appear today. I can only work with the old session that hasn't been closed yet :(
    It looks like the image below, once open code crashes, I can't control the terminal's viewport with the mouse.
    
13. Mte90 commented on May 7, 2026

    

    Mte90

    on May 7, 2026

    More actions

    I can confirm that downgrading to 1.14.33 works, just remember to disable the autoupdate.

    👍React with 👍1Reacted by shiyan-salt
14. sukris commented on May 9, 2026

    

    sukris

    on May 9, 2026

    Last edited by sukris

    Author

    More actions

    Closing this from my side with the local resolution and the troubleshooting method that worked for me.

    This should not be read as confirmation that the underlying Bun / TUI shutdown crash is fixed upstream. Other users may still hit the same bundled Bun 1.3.13 NAPI FATAL ERROR path, and the later comments here suggest there may be more than one trigger. In my case, the issue is no longer blocking my local OpenCode usage after isolating a local plugin/native dependency trigger.

    What the AI/agent investigation did

    I used an OpenCode/AI-agent style investigation rather than trying random reinstall steps. The useful workflow was:

    1. Capture the exact crash signature.

       • panic: NAPI FATAL ERROR: Error::New napi_create_error
       • oh no: Bun has crashed
       • trace trap opencode

    2. Separate system Bun from bundled Bun.

       • My system bun was not the runtime used by OpenCode.
       • The OpenCode binary embedded Bun v1.3.13, so changing the system Bun version was not expected to fix this class of crash.

    3. Narrow the reproduction surface.

       • Interactive TUI exit was the strongest signal.
       • Ctrl + C, /exit, and later reports of /quit all pointed at shutdown / teardown / cleanup behavior.
       • Non-interactive opencode run ... plus scripted SIGINT did not reproduce the same crash reliably for me.

    4. Inspect OpenCode logs and macOS crash reports instead of only the terminal output.

       • OpenCode logs: ~/.local/share/opencode/log/
       • macOS reports: ~/Library/Logs/DiagnosticReports/opencode-*.ips

    5. Compare OpenCode plugin loading with the local config.

       • I checked which plugins were configured and which ones were actually loaded.
       • I also checked plugin load failures and native modules present in the process.

    6. Form one hypothesis at a time and verify it.

       • The strongest local evidence was not a normal JavaScript exception.
       • The macOS crash reports pointed at native dependency cleanup involving ONNX/WebGPU/sharp-related modules.

    Using OpenCode itself to investigate this kind of crash

    The most useful part was letting an OpenCode/AI agent do the boring evidence collection and comparison, while explicitly instructing it not to jump to a reinstall or random fix.

    A prompt that worked well for me was:

    Investigate this OpenCode crash systematically. Do not change files yet.
    
    Goal:
    Find whether the crash is caused by OpenCode itself, bundled Bun, my system Bun, a plugin, MCP config, or a local native dependency.
    
    Crash signature:
    <paste the full terminal crash output here>
    
    Please:
    1. Check opencode and system bun versions.
    2. Determine whether OpenCode is using bundled Bun or system Bun.
    3. Read recent OpenCode logs under ~/.local/share/opencode/log/.
    4. Inspect macOS crash reports under ~/Library/Logs/DiagnosticReports/opencode-*.ips.
    5. Identify native modules or symbols in the crash report.
    6. Compare loaded plugins with ~/.config/opencode/opencode.jsonc and ~/.config/opencode/package.json.
    7. Separate confirmed evidence from hypotheses.
    8. Propose the smallest reversible fix first.
    9. After any fix, verify with opencode --print-logs mcp list and opencode --print-logs models.
    

    Useful commands for the agent to run:

    opencode --version
    which bun
    bun --version
    opencode --print-logs mcp list
    opencode --print-logs models

    Useful files/locations for the agent to inspect:

    ~/.local/share/opencode/log/
    ~/.local/share/opencode/
    ~/.config/opencode/opencode.jsonc
    ~/.config/opencode/package.json
    ~/Library/Logs/DiagnosticReports/opencode-*.ips
    

    What the agent should look for:

    - Whether the crash happens in interactive TUI only or also in opencode run
    - Whether the latest log shows plugin load failures
    - Whether crash reports mention native modules such as onnxruntime, sharp, libvips, sqlite, watcher, or other .node/.dylib files
    - Whether a configured plugin pulls in native dependencies
    - Whether disabling one plugin changes the result
    - Whether a new opencode-*.ips report appears after each verification run
    

    The key instruction is: make the AI agent prove or disprove one hypothesis at a time. In my case that avoided a full reinstall and led to the smaller fix of removing one plugin dependency chain.

    Local root cause in my environment

    For my later local crashes, the strongest evidence pointed to the opencode-agent-skills plugin dependency chain, specifically native dependencies pulled through something like:

    opencode-agent-skills -> @huggingface/transformers -> onnxruntime / sharp native modules
    

    The crash reports included symbols/modules such as:

    onnxruntime_binding.node
    libonnxruntime.1.21.0.dylib
    sharp-darwin-arm64.node
    libvips-cpp.8.17.3.dylib
    onnxruntime::webgpu::WebGpuContextFactory
    wgpu::Instance::~Instance()
    

    That made the most likely local failure mode: native dependency initialization/cleanup during OpenCode startup or shutdown, triggered by the plugin environment, not by my project code.

    Local fix that worked for me

    I did not reinstall OpenCode first. The minimal fix was to remove the risky plugin dependency chain:

    1. Remove opencode-agent-skills from ~/.config/opencode/opencode.jsonc plugin config.
    2. Remove opencode-agent-skills from ~/.config/opencode/package.json.
    3. Refresh the lockfile and prune unused dependencies from the config directory.
    4. Keep the superpowers plugin enabled.
    5. Re-run basic OpenCode commands with --print-logs and check that no new macOS .ips crash report was generated.

    After this, my local verification passed:

    opencode --version
    opencode --print-logs mcp list
    opencode --print-logs models
    

    The latest logs no longer loaded opencode-agent-skills, and I did not get new opencode-*.ips crash reports during those checks.

    General recommendation for others

    If you hit this crash, I would not start with a full reinstall. A safer AI/agent-assisted troubleshooting order is:

    1. Save the exact terminal crash output.
    2. Ask OpenCode/AI to perform a read-only investigation first, using the prompt above.
    3. Check opencode --version and remember that the binary may use bundled Bun, not your system Bun.
    4. Check ~/.local/share/opencode/log/.
    5. Check ~/Library/Logs/DiagnosticReports/opencode-*.ips for native modules/symbols.
    6. Temporarily disable third-party plugins.
    7. Re-test with opencode --print-logs mcp list and opencode --print-logs models.
    8. If plugin isolation fixes it, re-enable plugins one at a time.
    9. If no plugin is involved, try the workaround mentioned above by others: downgrade to 1.14.33 and disable autoupdate.

    So, for my machine, the practical resolution was plugin isolation/removal, not changing project code. Closing this issue from my side because my local environment is now stable enough after that mitigation.

    ❤️React with ❤️3Reacted by DO2THX, Mengjiao LIU and Memo
15. sukris

    closed this as completedon May 9, 2026
16. gretel commented on May 9, 2026

    

    gretel

    on May 9, 2026

    More actions

    thanks for the analysis!

    opencode-agent-skills -> @huggingface/transformers -> onnxruntime / sharp native modules

    i've tried disabling this particular plugin and voila... back to using latest release. would you mind openeing an issue at the plugin's upstream? thanks and regards