Description
The CLI shipped via opencode-ai@1.17.15 (bin/opencode.exe, ~162 MB, Windows x64) hangs indefinitely the moment a message is sent. The desktop app @opencode-aidesktop on the same machine, same API key, same model, connected to same providerID=opencode-go, works normally.
What's observed (not inferred):
1.opencode run "say hi" (non-interactive) prints > build · qwen3.7-plus and then never produces output. No log line after llm runtime selected in ~/.local/share/opencode/log/opencode.log. Not a TUI/rendering issue — the non-interactive run command reproduces identically.
2.Get-NetTCPConnection -OwningProcess -State Established shows a connection to 2606:4700:78::90:0:143:443 that stays Established but never delivers data.
3.Same command against the desktop app shows it connected to IPv4 172.65.90.21:443 and works fine.
4.curl -4 https://api.opencode.ai → 200 (~0.9s). curl -6 → returns 000 within ~1ms (IPv6 path silently drops).
5.Adding 104.20.32.17 api.opencode.ai to C:\Windows\System32\drivers\etc\hosts does not fix the CLI — so this is not just a DNS-preference issue the hosts file can override.
6.The desktop app's own logs at startup show the IPv6 path timing out, then a retry over IPv4 succeeding — it recovers; the CLI does not.
Plugins
No response
OpenCode version
CLI: opencode-ai@1.17.15 (opencode.exe 1.17.15) Desktop: @opencode-aidesktop (current beta) — works correctly on the same host
Steps to reproduce
1.Windows 11 host with: IPv4 to api.opencode.ai working; IPv6 TCP handshake to Cloudflare anycast succeeds but application data is silently dropped; DNS hijacked by ISP (sc.10086.cn).
2.npm install -g opencode-ai, then opencode → /connect → OpenCode Go → paste API key → /models → pick qwen3.7-plus.
3.Quit TUI. Run the non-interactive form: opencode run "say hi".
4.Observe it prints > build · qwen3.7-plus and hangs. Get-NetTCPConnection -OwningProcess shows Established connection to 2606:4700:78::90:0:143:443.
5.Start @opencode-aidesktop with the same key/model → it answers within seconds. Its process shows Established connection to IPv4 172.65.90.21:443.
Screenshot and/or share link
No response
Operating System
Windows 11 Pro
Terminal
Windows PowerShell 5.1 (System32\WindowsPowerShell\v1.0\powershell.EXE). Issue is not TUI-specific — opencode run (non-interactive) reproduces the same hang.
###Suggested fix / ask
The desktop app recovers from the same failure: its logs show the IPv6 path timing out then retrying over IPv4 and succeeding (Happy Eyeballs–style fallback). The CLI does not. I'd like to request one of:
(preferred) Implement the same IPv6-timeout → IPv4-fallback behavior the desktop app already exhibits, so the CLI auto-recovers in this environment without user config changes; or
Provide an opt-in flag / env var to force the CLI to use IPv4 only (e.g. --ipv4-only or OPENCODE_IPV4=1) that bypasses IPv6 entirely. The hosts file is not sufficient on its own — the CLI keeps attempting the IPv6 path — so a real force-IPv4 switch would be valuable for users on networks where IPv6 handshakes silently drop.
Description
The CLI shipped via opencode-ai@1.17.15 (bin/opencode.exe, ~162 MB, Windows x64) hangs indefinitely the moment a message is sent. The desktop app @opencode-aidesktop on the same machine, same API key, same model, connected to same providerID=opencode-go, works normally.
What's observed (not inferred):
1.opencode run "say hi" (non-interactive) prints > build · qwen3.7-plus and then never produces output. No log line after llm runtime selected in ~/.local/share/opencode/log/opencode.log. Not a TUI/rendering issue — the non-interactive run command reproduces identically.
2.Get-NetTCPConnection -OwningProcess -State Established shows a connection to 2606:4700:78::90:0:143:443 that stays Established but never delivers data.
3.Same command against the desktop app shows it connected to IPv4 172.65.90.21:443 and works fine.
4.curl -4 https://api.opencode.ai → 200 (~0.9s). curl -6 → returns 000 within ~1ms (IPv6 path silently drops).
5.Adding 104.20.32.17 api.opencode.ai to C:\Windows\System32\drivers\etc\hosts does not fix the CLI — so this is not just a DNS-preference issue the hosts file can override.
6.The desktop app's own logs at startup show the IPv6 path timing out, then a retry over IPv4 succeeding — it recovers; the CLI does not.
Plugins
No response
OpenCode version
CLI: opencode-ai@1.17.15 (opencode.exe 1.17.15) Desktop: @opencode-aidesktop (current beta) — works correctly on the same host
Steps to reproduce
1.Windows 11 host with: IPv4 to api.opencode.ai working; IPv6 TCP handshake to Cloudflare anycast succeeds but application data is silently dropped; DNS hijacked by ISP (sc.10086.cn).
2.npm install -g opencode-ai, then opencode → /connect → OpenCode Go → paste API key → /models → pick qwen3.7-plus.
3.Quit TUI. Run the non-interactive form: opencode run "say hi".
4.Observe it prints > build · qwen3.7-plus and hangs. Get-NetTCPConnection -OwningProcess shows Established connection to 2606:4700:78::90:0:143:443.
5.Start @opencode-aidesktop with the same key/model → it answers within seconds. Its process shows Established connection to IPv4 172.65.90.21:443.
Screenshot and/or share link
No response
Operating System
Windows 11 Pro
Terminal
Windows PowerShell 5.1 (System32\WindowsPowerShell\v1.0\powershell.EXE). Issue is not TUI-specific — opencode run (non-interactive) reproduces the same hang.
###Suggested fix / ask
The desktop app recovers from the same failure: its logs show the IPv6 path timing out then retrying over IPv4 and succeeding (Happy Eyeballs–style fallback). The CLI does not. I'd like to request one of:
(preferred) Implement the same IPv6-timeout → IPv4-fallback behavior the desktop app already exhibits, so the CLI auto-recovers in this environment without user config changes; or
Provide an opt-in flag / env var to force the CLI to use IPv4 only (e.g. --ipv4-only or OPENCODE_IPV4=1) that bypasses IPv6 entirely. The hosts file is not sufficient on its own — the CLI keeps attempting the IPv6 path — so a real force-IPv4 switch would be valuable for users on networks where IPv6 handshakes silently drop.