Summary
The app only calls OpenCode V1 HTTP API paths (/global/health, /session, /session/{id}/prompt_async, …). OpenCode V2 servers expose only /api/*, and unmatched V1 paths fall through to the V2 web UI catch-all and return 200 text/html. The app hands that HTML to JSONDecoder, so Test Connection fails with an opaque Foundation error and the app cannot connect to any V2 server at all.
There is no configuration or host setting that works around this. It affects every user on OpenCode V2, not just a specific setup.
Environment
- App: V1.0 Build 27, 12 Sep 26
- opencode server version:
2.0.16 (V2, /api/* only)
- For comparison, tested against
1.18.32 (V1)
- OS: Windows_NT 10.0.26200 (server host); iPhone client
- Transport: Host profile, Connection Type = Direct, with Basic Auth
- Network: LAN, plain HTTP
Reproduction
- Install and run any OpenCode V2 server:
opencode serve --hostname 0.0.0.0 --port 49374
- In the app: Settings → Hosts → Add Host
- Set Connection Type = Direct, and OpenCode URL to the server address (e.g.
http://192.168.x.x:49374)
- Enter the Basic Auth username and password in the Basic Auth section
- Tap Test Connection
Expected Behavior
Test Connection should succeed against an OpenCode V2 server, and the app should be able to list sessions, browse files, and send prompts.
Actual Behavior
Test Connection fails. The error shown is:
The data could not be read because it is not in the correct format.
This is a JSONDecoder failure — the response body is HTML, not JSON. It carries no indication that an API version mismatch is the cause, which makes it hard to diagnose from the app alone.
Two related symptoms, depending on the address entered:
| OpenCode URL |
Result |
LAN address, e.g. http://192.168.x.x:49374 |
The data could not be read because it is not in the correct format |
Tailscale address, e.g. http://100.x.x.x:49374 |
An SSL/TLS error |
Root cause
The V1 paths the app calls return the V2 web UI's HTML with HTTP 200 rather than a 404 or a JSON error:
GET /global/health -> 200 <!doctype html> <html lang="en" ...>
GET /session -> 200 <!doctype html> <html lang="en" ...>
On a V1 server the same request returns proper JSON:
GET /global/health -> 200 {"healthy":true,"version":"1.18.32"}
Confirmed by running 1.18.32 as a sidecar — the app's expected endpoints are all present and correct there, so this is strictly a protocol mismatch and not a config, auth, or networking problem.
V2 paths currently served include /api/info, /api/session, /api/session/{sessionID}/prompt, /api/config, /api/provider, /api/fs/list, /api/fs/read/*, and /openapi.json.
This is more than a prefix change. prompt_async → prompt, file → /api/fs/list and /api/fs/read/*, find/file → /api/fs/find. And at least two endpoints have no V2 equivalent I could find: there is no todo route, and no session/status route (/api/session/active looks like a different concept). Those may have been folded into message parts or replaced outright rather than renamed — happy to be wrong here, it's just what I found in /openapi.json.
Workaround
Using the V2 web UI in Safari works. A pairing link from opencode pair signs in via cookie and loads the full V2 interface:
opencode pair --url http://192.168.x.x:49374
Not ideal on a phone, so a native V2 client would still be appreciated.
Additional Context
- This is not a regression — the app has never supported V2. OpenCode V2 is now GA and V1 will become less prevalent as the main install, so the gap blocks the primary client path.
/api/experimental/migration/v1 exists on the server but only covers V1 session history migration, not API compatibility. There is no V1 compatibility shim.- I hope this is easy to triage.
- Happy to test a build against a V2 server, or provide more detail on any endpoint in the list. I can also supply the full set of V1 paths the app currently requests if that helps with the migration.
Thanks for maintaining this — it's a great client, and V2 support would make it my daily driver.
Summary
The app only calls OpenCode V1 HTTP API paths (
/global/health,/session,/session/{id}/prompt_async, …). OpenCode V2 servers expose only/api/*, and unmatched V1 paths fall through to the V2 web UI catch-all and return200 text/html. The app hands that HTML toJSONDecoder, so Test Connection fails with an opaque Foundation error and the app cannot connect to any V2 server at all.There is no configuration or host setting that works around this. It affects every user on OpenCode V2, not just a specific setup.
Environment
2.0.16(V2,/api/*only)1.18.32(V1)Reproduction
http://192.168.x.x:49374)Expected Behavior
Test Connection should succeed against an OpenCode V2 server, and the app should be able to list sessions, browse files, and send prompts.
Actual Behavior
Test Connection fails. The error shown is:
This is a
JSONDecoderfailure — the response body is HTML, not JSON. It carries no indication that an API version mismatch is the cause, which makes it hard to diagnose from the app alone.Two related symptoms, depending on the address entered:
http://192.168.x.x:49374The data could not be read because it is not in the correct formathttp://100.x.x.x:49374Root cause
The V1 paths the app calls return the V2 web UI's HTML with HTTP 200 rather than a 404 or a JSON error:
On a V1 server the same request returns proper JSON:
Confirmed by running
1.18.32as a sidecar — the app's expected endpoints are all present and correct there, so this is strictly a protocol mismatch and not a config, auth, or networking problem.V2 paths currently served include
/api/info,/api/session,/api/session/{sessionID}/prompt,/api/config,/api/provider,/api/fs/list,/api/fs/read/*, and/openapi.json.This is more than a prefix change.
prompt_async→prompt,file→/api/fs/listand/api/fs/read/*,find/file→/api/fs/find. And at least two endpoints have no V2 equivalent I could find: there is notodoroute, and nosession/statusroute (/api/session/activelooks like a different concept). Those may have been folded into message parts or replaced outright rather than renamed — happy to be wrong here, it's just what I found in/openapi.json.Workaround
Using the V2 web UI in Safari works. A pairing link from
opencode pairsigns in via cookie and loads the full V2 interface:Not ideal on a phone, so a native V2 client would still be appreciated.
Additional Context
/api/experimental/migration/v1exists on the server but only covers V1 session history migration, not API compatibility. There is no V1 compatibility shim.Thanks for maintaining this — it's a great client, and V2 support would make it my daily driver.