Glob tool fails with WebAssembly parsing error in WSL2

[MaoMao-Kun]

Description

The glob tool fails with WebAssembly parsing error for ANY pattern. Other tools (read, edit, bash) work normally.
Error message:
WebAssembly.Module doesn't parse at byte 175: wasm-simd is not enabled, in function at index 81
This error mentions wasm-simd which suggests WebAssembly SIMD instructions are not enabled in the Node.js runtime under WSL2.

Plugins

No response

OpenCode version

1.4.6

Steps to reproduce

1. Run opencode in WSL2 environment
2. AI uses glob command:
   • glob pattern: "*.json"
   • glob pattern: "*"
   • glob pattern: "**/*"

Screenshot and/or share link

Operating System

WSL2 (Ubuntu/Linux) / Kernel: Linux 6.6.87.2-microsoft-standard-WSL2 / Architecture: x86_64

Terminal

bash (xterm-256color)

[github-actions]

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

• WASM ripgrep SIMD requirement breaks @ file fuzzy search on CPUs without AVX2 support #22617: Same error message (WebAssembly.Module doesn't parse at byte 175: wasm-simd is not enabled) and same version (1.4.6) — root cause is WASM SIMD not being supported, which in WSL2 may also be due to the kernel not enabling SIMD for WebAssembly (similar to CPUs without AVX2 support).

[dhanushreddy291]

+ facing same issue rendering opencode unusable

Operating system:
Ubuntu 24.04 Server as a VM on Proxmox

[niklas88]

This indeed looks like the same issues seen in #22617 which sadlly was closed as complete despite definitely still being an issue on v1.4.7. I'm also hitting the same issue on bare metal Linux on an Intel N5105 while the same opencode and same OS works fine on an Intel N100. So this does seem related to the CPU version rather than being about virtualization (WSL2 or Proxmox). It also seems to be new in a recent opencode version as I was able to use opencode v1.4.3 perfectly fine on the same machine before.

As stated in that issue a trivial way to reproduce is using:

opencode debug rg files --limit 5

Since this could very well be a bug in the WASM implementation or wasm-simd package I wonder if as a stop gap it makes sense to roll back to native ripgrep or at the very least make that an option. For me opencode just regressed from very nice and useful to completely broken.

[dqbpqdpb]

Experiencing the same issue on Debian Trixie (Node.js v24.14.1 LTS):

WebAssembly.Module doesn't parse at byte 204: wasm-simd is not enabled, in function at index 28

Attempted fixes that did NOT work:

• Upgraded from Node.js 20.19.2 → 24.14.1 (LTS)
• Removed oh-my-opencode plugin and its remnants

This confirms the bug is in OpenCode's embedded WASM modules, not the system Node.js or plugins. Same as WSL2 environment.

[arlaneenalra]

I'm seeing the same on an older linux machine I use as a vm server.

[mwhouser]

I'm hitting the same issue.

Ubuntu 24.04 VM on Proxmox.

[Yh0x1n]

I have the same issue on Fedora 43 Silverblue, native, and OpenCode 1.4.10

[yookibooki]

Confirming this is still happening on v1.4.6+. Same WebAssembly.Module doesnt parse ... wasm-simd is not enabled error here. v1.4.3 is the last known working version, and v1.4.4 introduced the embedded WASM ripgrep backend (#21703), so the regression seems to start there.

[dqbpqdpb]

1.4.17，still the same, Debian Trixie (Node.js v24.14.1 LTS)

✱ Glob "*"
WebAssembly.Module doesn't parse at byte 204: wasm-simd is not enabled, in function at index 28