[WSL2] single opencode run deadlocks during bootstrap before provider dispatch (no plugins, no concurrent process, no zombie child) #46142

Description

On WSL2, a single non-interactive opencode run hangs indefinitely during instance bootstrap, before the selected provider is contacted. The process remains alive at near-zero CPU with its main thread in epoll and worker threads in futex waits.

This reproduces with:

• OpenCode 1.18.25;
• --pure and no plugins;
• exactly one OpenCode process;
• a local Ollama model whose API is healthy;
• an OpenCode Zen free model;
• the repository on /mnt/c (drvfs);
• a fresh Git repository on native WSL ext4;
• the existing state database and a fresh state database;
• the normal user configuration and with the user-level configuration isolated.

The hang occurs before provider dispatch, so changing the provider or model does not affect it.

Plugins

None. opencode debug info reports:

plugins:
none

The problem also reproduces with --pure.

OpenCode version

1.18.25

Installation: standalone Linux x64 binary installed under ~/.opencode/bin/opencode.

Environment

Windows: 10.0.26200.8875
WSL: 2.7.11.0
Distribution: Ubuntu 24.04
Kernel: 6.18.33.2-microsoft-standard-WSL2
Architecture: x86_64
Terminal: bash / xterm-256color
Ollama: 0.32.15
Local model: qwen3:4b

There is no separate Node.js installation inside this WSL distribution; OpenCode is the standalone bundled executable.

Steps to reproduce

1. Start a healthy local Ollama server and confirm that the selected model responds through the Ollama API.
2. In a Git repository under WSL2, ensure that no other OpenCode process is running.
3. Run:

timeout 120s opencode --pure --print-logs --log-level DEBUG run \
  --model ollama/qwen3:4b \
  "Reply with exactly OK"

4. Observe that the command produces no model response and is terminated by the external timeout.

The same behavior was reproduced in a fresh Git repository on native WSL ext4 and with the free opencode/mimo-v2.5-free model.

Expected behavior

opencode run should create the session, dispatch the prompt to the selected provider, and either return the model response or fail with a bounded, actionable error.

Actual behavior

The last relevant debug messages are:

message="creating instance"
message=fromDirectory
message=bootstrapping
message="all LSPs are disabled"
message="all formatters are disabled"
message=init

Approximately 58 seconds later, the only additional line is:

message=cleanup prune=7.days

No session/provider/LLM streaming log follows, and the process never exits by itself.

For comparison, the binary-only startup diagnostic is healthy:

opencode --print-logs --log-level DEBUG debug startup

It completes in approximately 494 ms.

Diagnostic evidence

/proc snapshot

During the hang:

main thread: do_epoll_wait
worker thread: futex_do_wait
worker thread: futex_do_wait
worker thread: poll_schedule_timeout

There are no child processes and no zombie Git processes.

Bounded strace

A 45-second strace -ff run, restricted to process/file/network/wait syscalls, shows:

1. The state database, WAL, and SHM files open successfully.
2. Repository-discovery Git commands all exit with status 0.
3. DNS and TLS access to models.opencode.ai succeeds.
4. The public model cache is written to a temporary file and atomically renamed to ~/.cache/opencode/models.json.
5. The resulting 4.3 MB model-cache file is valid JSON.
6. No connection is attempted to the selected Ollama endpoint on port 11434.
7. After initialization, the main thread repeatedly performs empty epoll_pwait2 calls while other threads wait on futexes until the external timeout sends SIGTERM.

Unlike issue #36840, running under strace -f does not make this hang disappear.

What has been ruled out

• Provider/model failure: direct Ollama API requests succeed; the hang also reproduces with a different provider.
• External plugins: --pure; debug info reports no plugins.
• Concurrent OpenCode instances: the failure reproduces with a single exclusive process.
• State database corruption or contention: the failure reproduces with a fresh state database.
• User-level configuration conflict: the failure reproduces with the user-level config isolated.
• drvfs/NTFS behavior: the failure reproduces in a native WSL ext4 Git repository.
• Model-cache corruption: the cache download, atomic rename, and JSON validation all succeed.
• Git child-process completion: all Git subprocesses exit successfully, and no zombie child exists during the hang.
• OpenCode binary startup: debug startup completes in about 494 ms.

Related issues and why this appears distinct

• WSL2: server event-loop deadlock (zombie git children) when Desktop app bootstraps multiple instances concurrently; drvfs project amplifies #36840: WSL2 serve deadlock during concurrent bootstrap of multiple instances, amplified by drvfs, with zombie Git children. This reproduction uses one run instance, also fails on ext4, has no zombie child, and remains hung under strace.
• opencode -c/-i TUI sessions hang permanently: zombie git child under project-copy-refresh snapshot step #40439: interactive -c/-i sessions hang on a zombie Git child during project-copy refresh. This reproduction is non-interactive run and has no child or zombie process while hung.
• opencode run hangs on WSL  #2692 / opencode hangs when trying to end it #1431: the model response is produced and shutdown hangs, or an MCP child prevents shutdown. Here provider dispatch never starts, there are no plugins/MCPs, and no response is produced.
• Concurrent opencode run instances deadlock during init (futex, no timeout) — second overlapping instance hangs forever #29395: concurrent opencode run instances deadlock on shared state. This reproduction occurs with exactly one process and also with a fresh state database.
• opencode run hangs forever (and silently) when the provider's baseURL refuses the TCP connection — unbounded retry schedule + non-interactive mode never surfaces the retry status #40330: provider connection refusal causes an unbounded retry. Here the provider socket is never attempted, and the selected local provider is healthy.

Request

Please add a bounded timeout or explicit error around the bootstrap-to-session/provider transition and investigate the unresolved event/futex wait in the standalone runtime on WSL2.

I can provide a further sanitized trace or targeted diagnostic output if maintainers specify the required syscall set or runtime instrumentation.