desktop: deleted last-opened folder leaves 404 LocationNotFoundError and empty model list #57247

Summary

OpenCode Desktop (2.0.32) remembers the last opened project folder in its local state database. If that folder is deleted outside the app, every HTTP request it makes to the background service (/api/provider, /api/model, /api/config, /api/location, /api/vcs, /api/integration) is sent with the now-invalid location and returns 404 LocationNotFoundError. The model selector stays empty, the app shows no error to the user, and it does not recover on relaunch — only resetting the Desktop's local state (or recreating the deleted folder) fixes it.

Environment

• opencode version: 2.0.32 (Desktop app 2.0.32 with bundled/staged CLI ~/.config/<app-dir>/cli/2.0.32-x64; shared background service @opencode/cli 2.0.32, channel latest)
• OS: Linux 7.0.0-38-generic (Ubuntu 24.04 based), x86_64, X11
• Terminal: N/A (Desktop app; CLI diagnostics were gathered from WarpTerminal)
• Shell: /bin/bash
• Install/channel: latest (both the app updater and the CLI report up-to-date at 2.0.32)
• Active plugins: none configured by the user (global config dir contains only cli.json and service.json)

Reproduction

1. Open OpenCode Desktop with a fresh state; it provisions a default project folder, e.g. /home/<user>/Documents/Default Project, which gets recorded in the app's local state DB (state table, key server → lastProject, plus per-tab directory entries).
2. Delete that folder outside the app (the app stays pointed at it).
3. Relaunch OpenCode Desktop.
4. The model selector opens empty; no providers/models load. Every relaunch reproduces it (observed on 6 consecutive launches over ~20 minutes).

Server-side log, on every launch, one 404 burst for each of these (note: only failed responses are logged — see below):

message="Sent HTTP response" ... http.method=GET http.url=/api/provider http.status=404
message="Sent HTTP response" ... http.method=GET http.url=/api/model    http.status=404
message="Sent HTTP response" ... http.method=GET http.url=/api/config   http.status=404
message="Sent HTTP response" ... http.method=GET http.url=/api/location http.status=404
message="Sent HTTP response" ... http.method=GET http.url=/api/vcs      http.status=404

Expected Behavior

When the remembered directory no longer exists on disk, the app should degrade gracefully — e.g. fall back to the home directory or a project picker, show a visible "location not found" state in the UI, and/or refetch when the server broadcasts provider.updated/model.updated events. Users would then self-heal without touching state files.

Actual Behavior

The UI shows no models and no error banner. Reproducing the Desktop's exact request confirms the failure mode:

$ GET /api/model?location[directory]=/home/<user>/Documents/Default%20Project

{"_tag":"LocationNotFoundError","location":{"directory":"/home/<user>/Documents/Default Project"},"message":"Location not found: /home/<user>/Documents/Default Project"}

HTTP 404

The same endpoints return the full provider/model list for an existing location[directory] (e.g. the home directory) with zero users-logged-in, so the models were available the whole time — the stale location alone broke every data request.

Additional Context

• Connectivity/auth were fine all along: the Desktop's main.log shows v2 CLI background service ready { probed: true, url: 'http://127.0.0.1:49xxxx' } and the SSE GET /api/event returned 200.
• The renderer log contains no network errors (only harmless font/ResizeObserver noise), so the user never sees why nothing loads.
• The app only queries once per launch: it never refetched on provider.updated/model.updated SSE events (fired routinely every ~30 minutes), which is why relaunching didn't help.
• Workarounds verified: (a) recreating the deleted folder makes all requests resolve immediately; (b) with the app closed, backing up ~/.config/<app-dir>/drafts.sqlite (+ -wal/-shm) and relaunching gives a clean state.
• Catalog of the launched app's main.log had no error/fail lines either — from the app's own logs alone this is truly silent.
• Diagnosis note: the background service logs only failed responses for these HttpApi routes (400/401/404/503 observed); successful 200s never appear in opencode.log, which initially suggested "the endpoints don't exist". If not intended, logging successes (at DEBUG level) would make triage much easier.