[BUG]: v1.15.13 web UI crashes with Settings context provider error

[bernhardberger]

Description

After upgrading the OpenCode web server from 1.15.12 to 1.15.13, the web UI rendered the global error boundary instead of the normal project/session UI. Existing sessions were still present and the backend API was healthy, but the web UI made session history appear broken/inaccessible.

The error shown in the browser was:

Error: Settings context must be used within a context provider
    at use (https://<host>/assets/index-Celomlsk.js:2:41524)
    at rn (https://<host>/assets/home-BhuYZCc1.js:2:11619)
    at https://<host>/assets/index-Celomlsk.js:2:15011
    at tt (https://<host>/assets/index-Celomlsk.js:2:4067)
    at Object.fn (https://<host>/assets/index-Celomlsk.js:2:14981)
    at Yb (https://<host>/assets/index-Celomlsk.js:2:6835)
    at gl (https://<host>/assets/index-Celomlsk.js:2:6592)
    at yf (https://<host>/assets/index-Celomlsk.js:2:8033)
    at C7 (https://<host>/assets/index-Celomlsk.js:2:8914)
    at YT (https://<host>/assets/index-Celomlsk.js:2:8286)

The error overlay showed Version: 1.15.12, while the backend health endpoint reported 1.15.13.

Downgrading the same install back to 1.15.12 fixed the web UI immediately and session history was visible again.

What still worked on 1.15.13

Backend/API state looked healthy:

GET /global/health -> 200 {"healthy":true,"version":"1.15.13"}
GET /project -> 200
GET /session?projectID=<project-id> -> 200, returned existing sessions
opencode session list -> showed existing sessions
sqlite integrity_check on opencode.db -> ok

So this did not look like data loss or database corruption. It looked like a web frontend/runtime regression.

Request/network observations

When loading the broken web UI on 1.15.13, these requests returned HTTP 200 before the error boundary appeared:

GET /
GET /assets/index-Celomlsk.js
GET /assets/index-B0YimF4S.css
GET /global/config
GET /provider
GET /path
GET /project
GET /global/health
GET /assets/home-BhuYZCc1.js
GET /global/event

The visible DOM showed the project picker/recent-projects area behind/under the error boundary, but clicking the project could not reach a usable session list because the same error persisted.

Reproduction shape

I do not yet have a minimal clean-room reproduction, but the observed reproduction was:

1. Run OpenCode web on Linux with existing local session history.
2. Upgrade from 1.15.12 to 1.15.13 using the official installer.
3. Start opencode web --port 8080 --hostname 0.0.0.0.
4. Open the web UI in Chromium/Chrome.
5. Observe the global error boundary with Settings context must be used within a context provider.
6. Verify that /session?projectID=... and opencode session list still return existing sessions.
7. Downgrade to 1.15.12 and restart the web server.
8. The same web UI/session history works again.

Environment

• OpenCode version with bug: 1.15.13
• Known-good version after downgrade: 1.15.12
• OS: Debian 13 / Linux x64
• Browser: Chromium/Chrome
• Mode: opencode web --port 8080 --hostname 0.0.0.0
• Config shown by /global/config:

{"$schema":"https://opencode.ai/config.json","plugin":["@tarquinen/opencode-dcp@latest"]}

Runtime env included OPENCODE_EXPERIMENTAL_BACKGROUND_SUBAGENTS=true. OPENCODE_EXPERIMENTAL_WEBSOCKETS=true had previously been enabled, but disabling it and restarting did not fix this web UI crash. The downgrade to 1.15.12 did.

Expected behavior

The 1.15.13 web UI should render normally and show existing sessions when the backend/session API is healthy.

Actual behavior

The 1.15.13 web UI crashes into the global error boundary with Settings context must be used within a context provider, making existing session history appear unavailable even though the backend still returns it.

Workaround

Downgrade OpenCode back to 1.15.12.

[bernhardberger]

Follow-up from my homelab retest: my earlier conclusion was too strong, and this may help others who hit the same error.

Environment:

• OpenCode backend: upgraded from 1.15.12 to 1.16.2
• Browser route: native web UI behind reverse proxy + Basic Auth
• Sidecar OpenChamber: 1.12.3, pointed at the same OpenCode backend

What happened:

1. I upgraded to 1.16.2 and loaded the native OpenCode UI in an existing browser context.
2. The UI showed the same global error boundary:
   • Settings context must be used within a context provider
   • assets included index-DC0DaFR5.js / home-Bf1yqW-8.js
   • the web footer showed Version: 1.16.0 while /global/health and CLI showed 1.16.2 (likely related to the stale web version issue in Opencode web shows old version stamp #30958).
3. I rolled back to 1.15.12; the same existing browser context still showed the same crash screen, which made it look like a persistent frontend/backend mismatch.
4. A clean isolated browser context against rolled-back 1.15.12 rendered normally.
5. I then re-upgraded to 1.16.2 and retested in a clean isolated browser context with cache bypassed.

Clean 1.16.2 retest result:

• / rendered normally.
• Direct project/session route rendered normally, e.g. /<base64url(/root/homelab)>/session/<session-id>.
• Browser console had no errors or warnings.
• Relevant frontend chunks and API calls returned HTTP 200, including /global/config, /project, /global/health, /session/<id>?directory=..., /session/<id>/message?..., /config?directory=..., /vcs/diff?..., etc.
• OpenChamber health stayed OK and saw the same OpenCode backend as ready.
• Only one opencode web --port 8080 backend process was running.

So at least for 1.16.2, the Settings context must be used within a context provider crash can be preserved by stale browser/site/cache state. Clearing site data / using a fresh browser context fixed it here. I am now keeping 1.16.2 deployed.

This does not prove every report is cache-related, but it is worth trying before assuming DB corruption or a bad backend migration.