You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
No, not there yet, buddy.
Tried on Win11 Git Bash and Linux Mint.
Claude says the core issue is that opencode serve V2 changed its health check endpoint from /global/health to /api/health (or similar), and the wrap is still polling the old path. So it spawns successfully but never sees "healthy".
opencode serve starts successfully (port 4100, password printed) but opencode-wrap times out with "did not become healthy in 20s" on both Windows and Linux Mint.
The wrap appears to be polling /global/health but OpenCode V2 returns HTML (the web UI) at that path. The actual API is at /api/health and requires an auth header — but the password is only known after the serve process starts and prints it to stdout.
Two things needed:
Update the health check path from /global/health to /api/health (or whatever the correct V2 path is)
Capture the password from opencode serve stdout and pass it as an auth header on all subsequent requests including the health check
Thanks for the detailed report. Both points you listed are implemented on main now:
V2 API + auth landed in 9cdab76 (Oct 15, 07:33 UTC). Health is probed via GET /api/info with HTTP basic auth, sessions/prompts use the /api/* routes, streaming reads session.text.delta.
Password handling: the wrapper generates a password and passes it to the spawned opencode serve through OPENCODE_SERVER_PASSWORD, so it never has to scrape stdout. If you point OPENCODE_BASE at a server you started yourself, export the same OPENCODE_SERVER_PASSWORD before starting the wrapper.
--version flag + version in /health (81aafcc, v0.4.1) so we can tell which build a report comes from.
About the "not there yet" test: the symptoms match the pre-V2 binary. A password printed by opencode serve means that server was not spawned by the new wrapper (when the wrapper passes the password, the server only prints server listening on ...), and the /global/health polling you mention comes from the old source. There were no tagged releases and no version flag, so there was no way to tell — sorry about that.
Please rebuild from current main and confirm the version:
Verified end to end (health, models, non-stream, stream, tool calls, attachments, session cleanup) on macOS with OpenCode 2.0.28 and 2.0.30, and in a clean Debian container with 2.0.30 installed via curl -fsSL https://opencode.ai/v2/install | bash (spawn, health, models, chat). Windows is covered by #1 but only compile-tested on our side, so a Win11 result would be welcome.
If it still fails on 0.4.1, please paste opencode-wrap --version, opencode --version, and the wrapper's startup log.
Working on Win11 with opencode-wrap 0.4.1 and opencode 2.0.28. Working on Linux.
Working in Obsidian Agent Client/Console plugins via acp bridge.
Health check passes, models endpoint responds, Hermes connects successfully via provider: custom, base_url: http://127.0.0.1:8000/v1. No manual patching needed as we tried before.
Awesome. Thanks for the quick fix from Hungary.
Activity
veerareddyvishal144 commentedon Oct 15, 2026
Yeah let me take a look since v2 just got released I havent yet tried it
bkutasi commentedon Oct 15, 2026
Second, I would love this to be updated. I'm currently rolling my over opencode-compat shim but its kinda flaky.
veerareddyvishal144 commentedon Oct 15, 2026
I have added compatibility with Opencode V2 do check it out
zanodor commentedon Oct 15, 2026
No, not there yet, buddy.
Tried on Win11 Git Bash and Linux Mint.
Claude says the core issue is that
opencode serveV2 changed its health check endpoint from/global/healthto/api/health(or similar), and the wrap is still polling the old path. So it spawns successfully but never sees "healthy".opencode servestarts successfully (port 4100, password printed) butopencode-wraptimes out with "did not become healthy in 20s" on both Windows and Linux Mint.The wrap appears to be polling
/global/healthbut OpenCode V2 returns HTML (the web UI) at that path. The actual API is at/api/healthand requires an auth header — but the password is only known after the serve process starts and prints it to stdout.Two things needed:
/global/healthto/api/health(or whatever the correct V2 path is)opencode servestdout and pass it as an auth header on all subsequent requests including the health checkveerareddyvishal144 commentedon Oct 15, 2026
I was using it on mac
We have a open pr for windows support let me check
Add --version flag and report the version in /health
veerareddyvishal144 commentedon Oct 15, 2026
Thanks for the detailed report. Both points you listed are implemented on
mainnow:GET /api/infowith HTTP basic auth, sessions/prompts use the/api/*routes, streaming readssession.text.delta.opencode servethroughOPENCODE_SERVER_PASSWORD, so it never has to scrape stdout. If you pointOPENCODE_BASEat a server you started yourself, export the sameOPENCODE_SERVER_PASSWORDbefore starting the wrapper.opencode.exe/ npmopencode.cmdresolution and a temp-dir default forWRAP_CWD.--versionflag + version in/health(81aafcc, v0.4.1) so we can tell which build a report comes from.About the "not there yet" test: the symptoms match the pre-V2 binary. A password printed by
opencode servemeans that server was not spawned by the new wrapper (when the wrapper passes the password, the server only printsserver listening on ...), and the/global/healthpolling you mention comes from the old source. There were no tagged releases and no version flag, so there was no way to tell — sorry about that.Please rebuild from current
mainand confirm the version:Verified end to end (health, models, non-stream, stream, tool calls, attachments, session cleanup) on macOS with OpenCode 2.0.28 and 2.0.30, and in a clean Debian container with 2.0.30 installed via
curl -fsSL https://opencode.ai/v2/install | bash(spawn, health, models, chat). Windows is covered by #1 but only compile-tested on our side, so a Win11 result would be welcome.If it still fails on 0.4.1, please paste
opencode-wrap --version,opencode --version, and the wrapper's startup log.zanodor commentedon Oct 16, 2026
Working on Win11 with opencode-wrap 0.4.1 and opencode 2.0.28. Working on Linux.
Working in Obsidian Agent Client/Console plugins via acp bridge.
Health check passes, models endpoint responds, Hermes connects successfully via provider: custom, base_url: http://127.0.0.1:8000/v1. No manual patching needed as we tried before.
Awesome. Thanks for the quick fix from Hungary.
veerareddyvishal144 commentedon Oct 17, 2026
Cool I am closing this issue