@hawkaii thank you for reporting.
I fixed this issue, try this fix and see if it works.

it works

could you fix the conflicts?

also can you describe what environment this is?

• @thdxr Conflict resolved.

also can you describe what environment this is?

• I had this issue on Debian 12.11, Linux 6.12.34, aarch64.
• I don't know the exact circumstances that cause this issue.

can you describe what environment this is?

I am also seeing this in a Linux 6.10.14 aarch64 container running in Docker Desktop on an M1 Max MBP, in either the Docker VMM or Apple Virtualization framework. This did not occur when using an amd64 version of the same container, though the TUI slowed to an absolute crawl when running in that manner (with or without using Rosetta on Apple Virtualization as well). So it seems like just generally Linux aarch64 was the cause, but only after v0.3.101 as mentioned here.

This may be related to the following Node.js behavior:

• linux-x64

~/opencode % ls ./node_modules/tree-sitter-bash/prebuilds/linux-x64/
tree-sitter-bash.node
~/opencode % node ./node_modules/tree-sitter-bash/prebuilds/linux-x64/tree-sitter-bash.node
~/opencode %

• linux-arm64

~/opencode % ls ./node_modules/tree-sitter-bash/prebuilds/linux-arm64/
tree-sitter-bash.node
~/opencode % node ./node_modules/tree-sitter-bash/prebuilds/linux-arm64/tree-sitter-bash.node
node:internal/modules/cjs/loader:1846
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: ~/opencode/node_modules/tree-sitter-bash/prebuilds/linux-arm64/tree-sitter-bash.node: cannot open shared object file: No such file or directory
    at Object..node (node:internal/modules/cjs/loader:1846:18)
    at Module.load (node:internal/modules/cjs/loader:1423:32)
    at Function._load (node:internal/modules/cjs/loader:1246:12)
    at TracingChannel.traceSync (node:diagnostics_channel:322:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:235:24)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:171:5)
    at node:internal/main/run_main_module:36:49 {
  code: 'ERR_DLOPEN_FAILED'
}

Node.js v22.18.0
~/opencode %

I couldn't find a command to call .node directly by bun, so I haven't been able to confirm the behavior by bun, but I think something similar will probably happen.

I'm running Debian Bullseye on WSL2 and experiencing the same issue. It's been unusable for a few days now. I’d appreciate a fix—thank you!

@lsj5031 you can rollback to v0.3.101 and set autoupdate false in the global config until it's fixed, thats what I did

I've identified the exact cause.
This is because the tree-sitter-bash library contains ./node_modules/tree-sitter-bash/prebuilds/linux-arm64/tree-sitter-bash.node and ./node_modules/tree-sitter-bash/prebuilds/linux-x64/tree-sitter-bash.node, both of which are files built for linux-x64.

• on linux-arm64

~/opencode %  ldd ./node_modules/tree-sitter-bash/prebuilds/linux-arm64/tree-sitter-bash.node
        not a dynamic executable
~/opencode %  ldd ./node_modules/tree-sitter-bash/prebuilds/linux-x64/tree-sitter-bash.node
        not a dynamic executable
~/opencode %

• on linux-x64

~/opencode %  ldd ./node_modules/tree-sitter-bash/prebuilds/linux-arm64/tree-sitter-bash.node
        linux-vdso.so.1 (0x00007ffc25d73000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f8871bc8000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8871b9c000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8871b98000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f88719a6000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f88718b8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f8871f98000)
~/opencode %  ldd ./node_modules/tree-sitter-bash/prebuilds/linux-x64/tree-sitter-bash.node
        linux-vdso.so.1 (0x00007ffe2a794000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f5e05969000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f5e0593d000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5e05939000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f5e05747000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f5e05659000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5e05d39000)
~/opencode %

I've been facing this same blocking issue on a raspberry pi 5 running bullseye as well. Happy to test the fix once it's ready!

This tree-sitter-bash issue occurs in v0.23.2 and later.
Downgrading tree-sitter-bash to v0.23.1 worked fine.
It works with tree-sitter-bash v0.25.0, but in that case type errors and build errors occur on the tree-sitter side.
It only worked fine with the combination of tree-sitter v0.23.3 + tree-sitter-bash v0.23.1.
Therefore, in this PR I have changed it to use that version combination.
This should allow it to work properly on arm64 without skipping features.
I cannot test whether it works in other environments such as macOS, and there is a possibility that other errors may occur in the library, so I left the skip function in case of an error as it is just in case.

it's working but the packages/sdk/js is not built when i run bun run packages/opencode/src/index.ts
it gives the following error

  ┃  error: Cannot find module '@opencode-ai/sdk' from                                     ┃
  ┃  '/home/hawkaii/code/git/opencode/packages/op                                          ┃
  ┃  encode/src/plugin/index.ts'                                                           ┃
  ┃                                                                                        ┃
  ┃  Bun v1.2.19 (Linux arm64)                                                             ┃
  ┃  hawkaii (03:46 PM)                      

i had to build it by running cd packages/sdk/js && bun run tsc
and then run the command

it's working but the packages/sdk/js is not built when i run bun run packages/opencode/src/index.ts

@hawkaii This error also occurs in the latest dev branch.
It is unrelated to this change.
Maybe bun dev or bun run --conditions=development packages/opencode/src/index.ts works.
#1567

@thdxr @adamdotdevin This PR is ready. 🙏

I can confirm that in my previously mentioned aarch64 container, without this patch on the dev branch at b459055 just now, I still see this error.

After applying this patch, bash commands work as expected again.

when is this fixed expected to be merged?

@thdxr or @adamdotdevin - @CaffeeLake has graciously been keeping this PR up to date and it would fix a serious issue facing arm64 users. Unfortunately it doesn't seem that the node-tree-sitter dependency is nearly as active as you two so unlikely to be fixed forward over there anytime soon. 🙏

getting the same issue, but only with certain models. ie Qwen in LMStudio via proxy
Fedora VM in MacOS, both arm
Error [ERR_DLOPEN_FAILED]: /tmp/.3bd968e1bc3ef7f7-00000001.node: cannot open shared object file: No such file or directory

@thdxr Thank you for checking.
It's certainly better to have an error.
I just removed the try catch that skips.
But, I updated the latest dev branch and it stopped working, so I'll check.

I discovered that downgrading tree-sitter-bash may not work properly.
Sorry. I didn't check this thoroughly.
Therefore, I changed part of the PR to use the WASM version in environments where the pre-build is broken, rather than downgrading tree-sitter-bash.
The reason I haven't integrated it into the WASM version is because it's just a little bit slow.
If neither version works, an error will be raised instead of being skipped.

@thdxr Is this specification okay?
If there's anything that needs improvement, I'll fix it.

Any progress on this one? It makes the eintire tool not usable for me:(

Any progress on this one? It makes the eintire tool not usable for me:(

@iliagerman
Since using the WASM version, no other changes have been made other than rebasing the latest dev branch.
I have confirmed that the latest version of this branch works in my environment.
It's currently awaiting review.
Did a recent change stop it working?

@thdxr Could you please review it again?
Details of the changes can be found here: #1546 (comment)

Did a recent change stop it working?

I've been using it on dev with this patch just fine to keep getting updates. So no, it's definitely still working here as well.

I suspect i hit this today but the message is slightly different so here goes:
The cli (v 0.4.40) appears to start fine, but after starting a model (in this case gemini 2.5 pro), it fails to run simple bash commands like 'mkdir'. I tried clearing cache folder and restarting, but same error. My humble request: please do some kind of self-test to detect the issue in startup before the model does - I burned a few $$ today while the model built up context reading files, but then it couldn't do anything with it!

Bash Build the demo app ┃ ResolveMessage: Cannot find module '/$bunfs/root/../../../tree-sitter-d8jpqavy.node' from '/$bunfs/root/opencode'

NixOS on aarch64.

@stevelr

I suspect i hit this today but the message is slightly different so here goes:

To avoid confusion, please create any bug reports other than those that occur in this branch in Issues rather than this PR.

please do some kind of self-test to detect the issue in startup before the model does

If I was to implement that feature in this PR, the change would likely cause the review to be rejected, further delaying the merge, so I won't address it in this PR.
Please create a new issue and resolve it in a separate PR.

PR looks good but did you check with an actual compiled version?

just tested on linux-x64, looks good