Opencode segfaults in NixOS+WSL #26846

Activity

1. github-actions

   assigned

   Hona

   on May 11, 2026
2. yipengsun commented on May 11, 2026

   

   yipengsun

   on May 11, 2026

   More actions

   I'm having the same issue on NixOS + WSL.

   👍React with 👍3Reacted by Anton Mu, fjara-dimacofi and mark-buck-vpsgroup
3. janczarn commented on May 11, 2026

   

   janczarn

   on May 11, 2026

   More actions

   I can also confirm this issue on NixOS in WSL.
4. fjararibet commented on May 12, 2026

   

   fjararibet

   on May 12, 2026

   More actions

   It's been happening for a while, I didn't catch it was a wsl issue. Version 1.4.3 is the latest one I got to work.

   nix run github:anomalyco/opencode/877be7e8e -- --version
   1.4.3+877be7e
   
5. HelloWorld017

   added a commit that references this issue on May 13, 2026

   revert: downgrade nixpkgs-latest

   ...

   8662037
6. mikebirdgeneau commented on May 13, 2026

   

   mikebirdgeneau

   on May 13, 2026

   Last edited by mikebirdgeneau

   More actions

   I just confirmed that v1.14.25 works for me narrowing down to between after v1.14.25 (working) and before v1.14.31 (failing)
7. alex-bartleynees commented on Jun 6, 2026

   

   alex-bartleynees

   on Jun 6, 2026

   Last edited by alex-bartleynees

   More actions

   I'm having the same issue with opencode on nixos-wsl too, works fine on my nixos desktop, some issue with the wsl kernel maybe?
8. OdysseusOperator commented on Jun 10, 2026

   

   OdysseusOperator

   on Jun 10, 2026

   Last edited by OdysseusOperator

   More actions

   Rolled back to 1.14.30, which works. So it is definetly something since version 1.14.31 acording to @alex-bartleynees post.

   Just a simple opencode --version is enough for me to check if it is crashing.
9. sonowz commented on Jun 17, 2026

   

   sonowz

   on Jun 17, 2026

   Last edited by sonowz

   More actions

   Looks like this is an issue of nixpkgs (or bun): NixOS/nixpkgs#520383

   By the way I managed to create a workaround for segfault:

   # 1. Copy the broken binary to a writeable area
   cp $(which .opencode-wrapped) /tmp/opencode-fixed
   chmod +w /tmp/opencode-fixed
   
   # 2. Force patchelf to rewrite the interpreter cleanly
   nix-shell -p patchelf --run "patchelf --set-interpreter \$(patchelf --print-interpreter /tmp/opencode-fixed) /tmp/opencode-fixed"
   
   
   # 3. Test if the repaired binary runs
   /tmp/opencode-fixed --version

   copy the /tmp/opencode-fixed binary somewhere to store it

   👍React with 👍2Reacted by mark-buck-vpsgroup and OdysseusOperator-eviden
10. sethkrasnianski

    added a commit that references this issue on Jul 3, 2026

    Add opencode, pinned to nixos-25.11 on WSL

    ...

    96925a9
11. atomic-235

    added a commit that references this issue on Jul 5, 2026

    fix: patchelf opencode to fix glibc mismatch segfault on WSL2

    ...

    1e69b37
12. kevst-dev

    added a commit that references this issue on Jul 9, 2026

    🐛 bug: Corregir segfault de opencode con glibc 2.42 mediante overlay

    ...

    a639aee
13. sethkrasnianski

    added a commit that references this issue on Jul 9, 2026

    Fix opencode WSL2 segfault in place instead of pinning stable

    ...

    1463efe
14. yuzow commented on Aug 3, 2026

    

    yuzow

    on Aug 3, 2026

    More actions

    I hit this on NixOS+WSL2 and tracked down the root cause. Note Opus helped me debug this so take that as you will. It's an ELF layout problem in the built binary, and the WSL2 kernel is stricter about it than mainline.

    opencode --version
    1.18.4

    uname -r
    6.6.87.2-microsoft-standard-WSL2

    nix --version
    nix (Nix) 2.34.8

    nixos-version
    26.11.20260729.0954f7e (Zokor)

    Root cause

    The crash is in ld.so, before any opencode code runs:

    .opencode-wrapp[1737907]: segfault at 6510e40 ip 00007603d54370e8 error 6
      in ld-linux-x86-64.so.2
    
    SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x6510e40}
    

    That address is not arbitrary. It's a copy relocation target:

    $ readelf -r bin/.opencode-wrapped | grep COPY
    000006510e40  R_X86_64_COPY  stderr@GLIBC_2.2.5 + 0
    000006510e20  R_X86_64_COPY  environ@GLIBC_2.2.5 + 0
    000006510e28  R_X86_64_COPY  stdout@GLIBC_2.2.5 + 0
    

    The binary's PT_LOAD segments are not in ascending p_vaddr order — the 85MB
    .bun payload segment is emitted first:

    $ readelf -lW bin/.opencode-wrapped | awk '/LOAD/{print $3, $6}'
    0x0000000006511000 0x515f000   <-- .bun payload, first
    0x00000000001ff000 0x001000
    0x0000000000200000 0x2806560
    0x0000000002b20c00 0x386f210
    0x0000000006390e10 0x180038    <-- RW/bss, ends at 0x6510e48
    

    The ELF spec requires PT_LOAD entries to be sorted by p_vaddr, and the
    kernel's ELF loader relies on that to size the .bss mapping. With the
    ordering wrong, the final page of .bss never gets mapped — and the three
    copy relocations above land in exactly that page. ld.so faults on the first
    one it writes.

    Why it's WSL2-specific

    Mainline kernels tolerate the bad ordering; the WSL2 kernel does not. That's
    consistent with the package building and caching fine on Hydra while failing
    on every WSL2 machine.

    It also explains a detail worth knowing for anyone trying to debug this under
    Nix: you cannot rebuild opencode locally on WSL2, because the build script's
    own smoke test crashes:

    building opencode-linux-x64
    Running smoke test: dist/opencode-linux-x64/bin/opencode --version
    Smoke test failed for opencode-linux-x64: ShellError: Failed with exit code 139
    

    That dist/ binary is pre-patchelf, straight out of bun build --compile, so
    the malformed layout is present the moment the executable is compiled — it is
    not introduced by any later Nix-side patching. Since the install-script binary
    reportedly works on WSL2, the released artifacts appear to have a correct
    segment order, which suggests this comes from how the binary is compiled in
    this build rather than from anything inherent to the released build. Running
    the readelf -lW command above against a release binary and a locally
    compiled one would confirm that directly.

    Fix / workaround

    Rewriting the interpreter to the value it already has is semantically a no-op,
    but it forces patchelf to regenerate the program header table, which emits the
    segments correctly sorted:

    patchelf --set-interpreter "$(patchelf --print-interpreter FILE)" FILE
    

    (Thanks @sonowz!)

    After that the .bun segment moves from first to last and the binary starts.
    Verified on 1.18.4 and reproduced identically on 1.18.11 (byte-identical
    segment addresses, so version bumps alone won't help).

    For nixpkgs users, this has to post-process the cached build rather than use
    overrideAttrs, since any override triggers the local rebuild that fails the
    smoke test above. The nixpkgs wrapper also hardcodes the original store path,
    so the fixed inner binary needs a fresh wrapper.

    A couple of questions for anyone who knows the build better than I do: is
    emitting sorted program headers something that can be controlled at compile
    time here, or is the post-hoc rewrite the practical route? And would a segment
    ordering check be worth adding to the release pipeline? The existing smoke test
    does catch this, but only on a kernel strict enough to fault, so it passes CI
    and surfaces later on WSL2.

    Happy to test any patch on a WSL2 box.
15. Moritz-Dorn commented on Aug 4, 2026

    

    Moritz-Dorn

    on Aug 4, 2026

    More actions

    hi,

    Just had the same problem and also ran it down with Opus.

    Confirming this on 1.18.12 with the readelf comparison you asked for, plus a
    caveat about the patchelf workaround.

    NixOS 25.05 (glibc 2.40), WSL2 kernel 6.6.87.2-microsoft-standard-WSL2.

    Release vs. locally built: segment order

    Release tarball (opencode-linux-x64.tar.gz, v1.18.12), --version works:

    $ readelf -lW opencode | awk '/LOAD/{print $3, $6}'
    0x0000000000200000 0x2063270
    0x00000000024c8400 0x36e5770
    0x0000000005baeb70 0x53b5490 <-- .bun payload, last, ascending
    
    

    Locally built from the flake (same version, segfaults):

    0x0000000006511000 0x5171000 <-- .bun payload, first
    0x00000000001ff000 0x001000
    0x0000000000200000 0x2806560
    0x0000000002b20c00 0x386f210
    0x0000000006390e10 0x180038
    
    

    So the released artifacts do have correct ordering and the local build does
    not — this comes from the build, not from the format. Fault address is
    0x6510e40, byte-identical to your 1.18.4 and 1.18.11 despite a 178 MB
    payload here vs. your 85 MB. Version bumps and payload size don't move it.

    Also not glibc-dependent: forcing the binary through the older 2.40 loader
    (ld-linux-x86-64.so.2 <binary> --version) faults identically.

    Caveat: not every patchelf invocation is safe

    --set-interpreter fixes it, but patchelf in general does not. Running
    --set-rpath on a working release binary breaks it:

    $ ./opencode --version # 1.18.12, exit 0
    $ cp opencode oc-patched
    $ patchelf --set-rpath /tmp oc-patched
    $ ./oc-patched --version # SIGSEGV
    
    

    Different failure mode, not a re-ordering issue:

    	local build	release + --set-rpath
    fault addr	0x6510e40	0x495fd9c6
    error code	6 (write)	4 (read)
    FS register	valid	0
    PT_LOAD order	unsorted	still ascending

    Segment order stays correct after --set-rpath (patchelf just prepends a
    segment at 0x1ff000 for the new header table), and the fault is a read at an
    address outside every mapping, before TLS setup. Looks like shifted file
    offsets invalidating Bun's recorded pointers into the appended blob — i.e. a
    second, independent way to break these binaries. Both reproduce with identical
    addresses across runs.

    Worth flagging since the workaround is itself a patchelf call: it has to be
    that specific no-op --set-interpreter and nothing else.

    Alternative for Nix users

    Skipping the local build entirely sidesteps both issues — fetch the release
    tarball, keep patchelf away from it, and let nix-ld provide the interpreter:

    pkgs.stdenvNoCC.mkDerivation rec {
      pname = "opencode";
      version = "1.18.12";
      src = pkgs.fetchurl {
        url = "https://github.com/anomalyco/opencode/releases/download/v${version}/opencode-linux-x64.tar.gz";
        hash = "sha256-ei47cGMGsE+/U1O2fZFrCAH82lZfnuAhvqKncgeWFFI=";
      };
      sourceRoot = ".";
      dontFixup = true;
      installPhase = "install -Dm755 opencode $out/bin/opencode";
    }

    with programs.nix-ld.enable = true;. No local build, no post-processing of a
    cached output, no wrapper rewrite. Running on WSL2 here.
16. github-actions commented on Oct 5, 2026

    

    github-actionsBot

    on Oct 5, 2026 – with GitHub Actions

    Contributor

    More actions

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
17. github-actions

    closed this as not plannedon Oct 5, 2026
18. kd2flz commented on Oct 14, 2026

    

    kd2flz

    on Oct 14, 2026

    More actions

    Is this really not going to be fixed upstream?