opencode: bun segfaults in wsl2

Nixpkgs version

Unstable (26.05)

Describe the bug

Since commit 9939a35, opencode is seg-faulting on my computer.

Steps to reproduce

opencode --version

Expected behaviour

Output: 1.14.33

Screenshots

No response

Relevant log output

Additional context

No response

System metadata

Obtained after I locked nixpkgs-unstable to the last working version:

system: "x86_64-linux"
host os: Linux 6.6.87.2-microsoft-standard-WSL2, NixOS, 25.11 (Xantusia), 25.11.10684.8fd9daa3db09
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.31.5
channels(root): "nixos-25.11, nixos-wsl-25.11.tar.gz, nixpkgs-unstable"
nixpkgs: /nix/store/fxi8lviscg8j27y7km48y7n6x34m8xqi-nixos-25.11/nixos

$ sudo nix-channel --list
nixos https://channels.nixos.org/nixos-25.11
nixos-wsl https://github.com/nix-community/NixOS-WSL/archive/refs/heads/release-25.11.tar.gz
nixpkgs-unstable https://github.com/NixOS/nixpkgs/archive/1b31087ac11ac1d2634ed938dd4761a917288938.tar.gz

Notify maintainers

Note for maintainers: Please tag this issue in your pull request description. (i.e. Resolves #ISSUE.)

I assert that this issue is relevant for Nixpkgs

I assert that this is a bug and not a support request.
I assert that this is not a duplicate of an existing issue.
I assert that I have read the NixOS Code of Conduct and agree to abide by it.

Is this issue important to you?

Add a 👍 reaction to issues you find important.

@delafthi

Maintainers: @delafthi @DuskyElf @graham33 @superherointj

I was not able to reproduce issue currently.

opencode master is 1.15.5
opencode nixos-unstable is 1.14.48

Are you still reproducing issue in nixos-unstable and master?

Away from my computer. I'll be able to test Friday or Saturday. Thanks 20 mai 2026 21:20:43 AI Systems Developer ***@***.***>:

…

[Image]*superherointj* left a comment (NixOS/nixpkgs#520383)[#520383 (comment)] I was not able to reproduce issue currently. * opencode master is *1.15.5* image.png (view on web)[https://github.com/user-attachments/assets/569e272f-7ed7-43e4-aace-96a912a73b5d] * opencode nixos-unstable is *1.14.48* image.png (view on web)[https://github.com/user-attachments/assets/e7a0b461-7f8c-4db8-8d6c-765639d6365b] Are you still reproducing issue in *nixos-unstable* and *master*? — Reply to this email directly, view it on GitHub[#520383 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAAM4HH2GVYJEHFATGVGHIL43YAQVAVCNFSM6AAAAACY7HYBMSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKMBRHAZDMMBZGA]. Triage notifications on the go with GitHub Mobile for iOS[https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675] or Android[https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub]. You are receiving this because you authored the thread. [Image de pistage][https://github.com/notifications/beacon/AAAM4HDRD3H2LBQJ4E4CEJD43YAQVBFCNFSM6AAAAACY7HYBMSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTYAAAAACDCUNIVKM4TFMFZW63VGMF2XI2DPOI.gif]

I'm experiencing the same issue with opencode-1.14.48 on WSL2. strace shows SIGSEGV during dynamic linking, right after loading glibc 2.42's libc/libpthread/libdl/libm:

--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x6510e40} ---

Has anyone had this issue in Linux and Darwin here?
Can you test latest opencode version (from master)?

These all actually seem to work, hoping that helps? 😅

npm exec [email protected] (current latest)
npm exec [email protected]
npm exec [email protected]
bunx [email protected]

I'm investigating a little further, if it's of major help I can verify on macOS as well but my gut feeling is saying it's a WSL2-related issue.

Looks like a Nix Bun issue, I can reproduce the segfault without Opencode like so:

echo 'console.log("hi", Bun.version)' > /tmp/nix-520383.ts && \
bun build --compile /tmp/nix-520383.ts --outfile /tmp/nix-520383 && \
/tmp/nix-520383

Note that bun here comes from (unstable) nixpkgs too. Running the same bun build --compile with the v1.3.13 binary downloaded from oven-sh/bun releases, on the same system does produce an executable that runs fine, only the nixpkgs-built bun produces broken --compile output. 🤯

I'm on NixOS. How do I reproduce this?

I'm not sure how to reproduce on NixOS, but for completeness sake:

Yes, WSL2 as mentioned in #520383 (comment), it matches the reporter's environment too.

Darwin is also good:

Not sure what you mean, didn't I do that in #520383 (comment)?

For the record, Claude thinks it found something, but this is above my level of experience with Nix and/or compiling Bun 😅

nixpkgs' bun derivation runs autoPatchelfHook on the upstream bun-linux-x64 binary. bun uses that on-disk binary as a template when producing bun build --compile standalones, so the patchelf-induced offset shifts propagate into every compiled output. The resulting standalones segfault in ld-linux's relocation phase. opencode (#520383) is the visible symptom, but anything that calls bun build --compile is affected.

Repro (no opencode needed)

echo 'console.log("hi", Bun.version)' > /tmp/hi.ts
bun build --compile /tmp/hi.ts --outfile /tmp/hi   # nixpkgs bun-1.3.13
/tmp/hi   # Segmentation fault (exit 139)

Same command with the upstream bun-linux-x64 binary (downloaded from the oven-sh/bun release zip, byte-identical to what nixpkgs starts from) on the same host produces a standalone that runs cleanly. Tested upstream 1.3.5 → 1.3.14 — all fine.

Isolating patchelf as the cause

bun source	bun runs?	`--compile` output runs?
upstream, untouched	✅	✅
upstream + `patchelf --set-interpreter <nix-glibc>` only	✅	❌ SIGSEGV
upstream + `--set-interpreter` and `--set-rpath`	❌	n/a
nixpkgs `bun-1.3.13` (autoPatchelfHook)	✅	❌ SIGSEGV

--set-interpreter alone is sufficient to break the output (the nix-store interp path is ~85 chars vs upstream's 26, so patchelf has to shift file offsets to fit). This is not the same as #510446 / #511533 — that fix ("drop --set-rpath") will not fix this.

Crash site

gdb backtrace of any broken standalone:

#0 memmove                          in ld-linux-x86-64.so.2
#1 _dl_relocate_object_no_relro     in ld-linux-x86-64.so.2
#2 _dl_relocate_object              ...
#3 dl_main / _dl_sysdep_start / _dl_start / _start

i.e. SIGSEGV inside the dynamic loader applying ELF relocations, before any user code runs.

Possible fix direction

Stop modifying bun's on-disk bytes. A buildFHSEnv wrapper around the untouched upstream binary works for me locally (verified: bun --version, bun build --compile, and a full opencode rebuild all succeed). But that approach produces --compile outputs that reference /lib64/ld-linux-x86-64.so.2, so they only run on hosts with an FHS-compatible /lib64 — fine on NixOS-WSL, regression on vanilla NixOS. A complete fix probably needs an upstream-bun change (env var to override --compile's self-binary lookup) so a thin ld.so wrapper becomes viable; I'll file that separately.

Happy to share the proof-of-concept override if useful.

System

nixpkgs-unstable (locked rev 1b31087-era)
NixOS 25.11 on WSL2, kernel 6.6.87.2-microsoft-standard-WSL2
glibc-2.42, x86_64 with AVX2

opencode: bun segfaults in wsl2 #520383 — opencode segfault (visible symptom)
lmstudio: lms segfaults on x86_64-linux; triggered by patchelf --set-rpath on Bun binary #510446 / lmstudio: remove unnecessary --set-rpath from patchelf to fix lms segfault #511533 — superficially similar patchelf-on-JS-bundle bug, but different failure mode and not a duplicate (see table above)
bun: 1.3.13 -> 1.4.0 #519796 — bun: 1.3.13 → 1.3.14 (won't fix this; upstream 1.3.14 is fine, problem is in the derivation)

In the past, we often waited for the next release of Bun, which usually resolved the issue. Perhaps Bun version 1.3.14 addresses the problem. However, it also causes build failures on Darwin, which is why it’s currently in draft state. These types of issues are extremely challenging to debug. Considering the recent push to rewrite Bun entirely in Rust using AI and the stability concerns associated with it, I’m uncertain about the best course of action. Perhaps we should downgrade to version 1.3.12 until the issue is resolved?

@cascornelissen

Would pinning bun version for WSL2 only, work for you @cascornelissen ?

Since this is a Bun bug, the implementation that needs to be branched off for WSL2 is the Bun implementation.

So, we have to:

open an issue for Bun package reporting breakage in WSL2 platform => bun: segfaults in wsl2 #523047
open a PR branching Bun for WSL2 platform.

@ttamttam

@ttamttam Update title to reflect the diagnosed issue:

opencode: bun segfaults in wsl2

open a PR branching Bun for WSL2 platform.

"WSL2" isn't a separate nixpkgs platform, it's just x86_64-linux, so there is no way to alter the package for WSL2 users.

open a PR branching Bun for WSL2 platform.

"WSL2" isn't a separate nixpkgs platform, it's just x86_64-linux, so there is no way to alter the package for WSL2 users.

Thanks for your answer.

I want to be able to test WSL2 somehow. I think, there must exist a possible solution to this to avoid causing future regressions. I know we don't have this solved right now. There must exist a possible solution, I mean. Such that packages also gets tested for WSL2 somehow. I opened an issue to discuss this here.

@delafthi

@delafthi Given niklaskorz's point that WSL2 is indistinguishable from x86_64-linux at build time, the only current option would be per-platform package splits — bun-wsl, opencode-wsl, etc. This is the wrong abstraction layer. Every Bun-dependent package would need its own WSL2 variant, which doesn't scale. Something upstream (Nix platform detection, or WSL2 kernel compatibility) needs to change instead. Opened an issue here: #523027

For those seeking a quick solution in the meantime, https://github.com/numtide/llm-agents.nix offers binary blobs that should work.

@superherointj

Hello.

changed the title, following @superherointj’s suggestion (thanks)
Of course, reproduced today when using nixpkgs-unstable https://channels.nixos.org/nixos-unstable

Pinned the last working version until the bun issue is solved:

let pinned_for_opencode = import (
  fetchTarball {
    url = "https://github.com/NixOS/nixpkgs/archive/1b31087ac11ac1d2634ed938dd4761a917288938.tar.gz";
    sha256 = "0zhnqvkl1qw8apxx20g1p2qhbph6q37qgggnp3zqcp9i4hknaymd";
  }) {}; in


  …


 environment.systemPackages = with pkgs; [
   …
   (pinned_for_opencode.opencode)
   …
 ];

$ opencode --version
1.14.33

Binary cache version also fails on native Linux on a ten-years-ish old machine.

ETA: bun is not a runtime dependency of opencode, but if I try it, I also get a failure.

On the other hand, it is SIGILL not SIGSEGV (both for opencode and bun)

@sonowz

On WSL1 it does not segfault like on WSL2. Instead, the wrapper fails to execve the Bun-compiled standalone with ENOEXEC:

execve("/nix/store/qwaln804k1cgacmzzrgkj7g7shcixg5i-opencode-1.17.7/bin/.opencode-wrapped", ["opencode", "--version"], 0x7fffe0d52310 /* 96 vars */) = -1 ENOEXEC (Exec format error)

Applying @sonowz’s workaround to .opencode-wrapped makes it executable on WSL1:

patchelf --set-interpreter $(patchelf --print-interpreter /tmp/opencode-fixed) /tmp/opencode-fixed

In my case this appears to work because patchelf rewrites/reorders the ELF program headers. Before the rewrite, the .bun LOAD segment appears before the lower-offset LOAD segments. After the rewrite, the LOAD segments are in a more conventional order, with the large .bun segment moved later.

Before:

[nix-shell:/tmp]$ readelf -l /nix/store/qwaln804k1cgacmzzrgkj7g7shcixg5i-opencode-1.17.7/bin/.opencode-wrapped | head -40

Elf file type is EXEC (Executable file)
Entry point 0x2b20c00
There are 10 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x00000000001ff040 0x00000000001ff040
                 0x0000000000000230 0x0000000000000230  R      0x8
  LOAD           0x000000000611a000 0x0000000006511000 0x0000000006511000
                 0x0000000003c4e000 0x0000000003c4e000  R      0x1000
  LOAD           0x0000000000000000 0x00000000001ff000 0x00000000001ff000
                 0x0000000000001000 0x0000000000001000  RW     0x1000
  INTERP         0x0000000000000270 0x00000000001ff270 0x00000000001ff270
                 0x0000000000000053 0x0000000000000053  R      0x1
      [Requesting program interpreter: /nix/store/57iz36553175g3178pvxjij8z5rcsd4n-glibc-2.42-61/lib/ld-linux-x86-64.so.2]
  LOAD           0x0000000000001000 0x0000000000200000 0x0000000000200000
                 0x0000000002806560 0x0000000002806560  R      0x1000
  NOTE           0x0000000000001254 0x0000000000200254 0x0000000000200254
                 0x0000000000000044 0x0000000000000044  R      0x4
  LOAD           0x0000000002809c00 0x0000000002b20c00 0x0000000002b20c00
                 0x000000000386f210 0x000000000386f210  R E    0x1000
  LOAD           0x0000000006079e10 0x0000000006390e10 0x0000000006390e10
                 0x0000000000095a80 0x0000000000180038  RW     0x1000
  TLS            0x0000000006079e10 0x0000000006390e10 0x0000000006390e10
                 0x0000000000000248 0x000000000004eb89  R      0x10
  DYNAMIC        0x000000000610d000 0x0000000006424000 0x0000000006424000
                 0x00000000000001f0 0x00000000000001f0  RW     0x8

 Section to Segment mapping:
  Segment Sections...
   00
   01     .bun
   02     .interp
   03     .interp
   04     .note.ABI-tag .note.gnu.build-id .dynsym .gnu.version .gnu.version_d .gnu.version_r .gnu.hash .hash .dynstr .rela.dyn .rela.plt .rodata
   05     .note.ABI-tag .note.gnu.build-id
   06     .text .init .fini .plt
   07     .tdata .tm_clone_table .data .fini_array .init_array .data.rel.ro __DATA,__jsc_opcodes __DATA,__wtf_config .dynamic .got .got.plt .bss

After:


[nix-shell:/tmp]$ readelf -l /nix/store/qwaln804k1cgacmzzrgkj7g7shcixg5i-opencode-1.17.7/bin/.opencode-wrapped

Elf file type is EXEC (Executable file)
Entry point 0x2b20c00
There are 10 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x00000000001ff040 0x00000000001ff040
                 0x0000000000000230 0x0000000000000230  R      0x8
  LOAD           0x0000000000000000 0x00000000001ff000 0x00000000001ff000
                 0x0000000000001000 0x0000000000001000  RW     0x1000
  INTERP         0x0000000000000270 0x00000000001ff270 0x00000000001ff270
                 0x0000000000000053 0x0000000000000053  R      0x1
      [Requesting program interpreter: /nix/store/57iz36553175g3178pvxjij8z5rcsd4n-glibc-2.42-61/lib/ld-linux-x86-64.so.2]
  LOAD           0x0000000000001000 0x0000000000200000 0x0000000000200000
                 0x0000000002806560 0x0000000002806560  R      0x1000
  NOTE           0x0000000000001254 0x0000000000200254 0x0000000000200254
                 0x0000000000000044 0x0000000000000044  R      0x4
  LOAD           0x0000000002809c00 0x0000000002b20c00 0x0000000002b20c00
                 0x000000000386f210 0x000000000386f210  R E    0x1000
  LOAD           0x0000000006079e10 0x0000000006390e10 0x0000000006390e10
                 0x0000000000095a80 0x0000000000180038  RW     0x1000
  TLS            0x0000000006079e10 0x0000000006390e10 0x0000000006390e10
                 0x0000000000000248 0x000000000004eb89  R      0x10
  DYNAMIC        0x000000000610d000 0x0000000006424000 0x0000000006424000
                 0x00000000000001f0 0x00000000000001f0  RW     0x8
  LOAD           0x000000000611a000 0x0000000006511000 0x0000000006511000
                 0x0000000003c4e000 0x0000000003c4e000  R      0x1000

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp
   03     .note.ABI-tag .note.gnu.build-id .dynsym .gnu.version .gnu.version_d .gnu.version_r .gnu.hash .hash .dynstr .rela.dyn .rela.plt .rodata
   04     .note.ABI-tag .note.gnu.build-id
   05     .text .init .fini .plt
   06     .tdata .tm_clone_table .data .fini_array .init_array .data.rel.ro __DATA,__jsc_opcodes __DATA,__wtf_config .dynamic .got .got.plt .bss
   07     .tdata .tbss
   08     .dynamic
   09     .bun

Fix opencode WSL2 segfault in place instead of pinning stable

Has anyone had this issue in Linux and Darwin here?

I have this problem is latest NixOS on unstable branch, the problem is my CPU does not support AVX and AVX2 which bun requires

$ nix run nixpkgs#bun
Illegal instruction        (core dumped) nix run nixpkgs#bun

ETA: bun is not a runtime dependency of opencode, but if I try it, I also get a failure.

although bun is not runtime dependency but i think it opencode is bundling bun somehow so when bundled bun is not baseline version(means it does not run without AVX2) opencode will fail too

AVX2 issues should be fixed with #547108. Could you test it on the master branch and let me know if it works?

Thank you for the reminding: I can confirm that it works now (I switched back to NixOS stable yesterday).

Navigation Menu

Repository navigation

opencode: bun segfaults in wsl2 #520383

Nixpkgs version

Describe the bug

Steps to reproduce

Expected behaviour

Screenshots

Relevant log output

Additional context

System metadata

Notify maintainers

I assert that this issue is relevant for Nixpkgs

Is this issue important to you?

Repro (no opencode needed)

Isolating patchelf as the cause

Crash site

Possible fix direction

System

Related

2 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

opencode: bun segfaults in wsl2 #520383

Description

Nixpkgs version

Describe the bug

Steps to reproduce

Expected behaviour

Screenshots

Relevant log output

Additional context

System metadata

Notify maintainers

I assert that this issue is relevant for Nixpkgs

Is this issue important to you?

Activity

Ben9986 commented on May 20, 2026

superherointj commented on May 20, 2026

ttamttam commented on May 20, 2026

cascornelissen commented on May 20, 2026

superherointj commented on May 20, 2026

cascornelissen commented on May 20, 2026

cascornelissen commented on May 20, 2026

superherointj commented on May 20, 2026

cascornelissen commented on May 20, 2026

cascornelissen commented on May 20, 2026

superherointj commented on May 20, 2026

cascornelissen commented on May 20, 2026

Repro (no opencode needed)

Isolating patchelf as the cause

Crash site

Possible fix direction

System

Related

delafthi commented on May 21, 2026

superherointj commented on May 21, 2026

2 remaining items

superherointj commented on May 22, 2026

superherointj commented on May 22, 2026

niklaskorz commented on May 22, 2026

superherointj commented on May 22, 2026

superherointj commented on May 22, 2026

delafthi commented on May 22, 2026

ttamttam commented on May 24, 2026

7c6f434c commented on May 24, 2026

haodeon commented on Jun 23, 2026

wtf9880 commented on Aug 19, 2026

delafthi commented on Aug 19, 2026

ttamttam commented on Aug 20, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions