anomalyco / anomalyco/opencode
tui: false "Session location unavailable" prompt after upgrade reconnect
@simonklee is already working on this.
Since Sep 16, 2026.
- Dominant language
- TypeScript
- Stars
- 209k
- Forks
- 27.5k
- PR merge metrics
- PR metrics pending
Description
Summary
After upgrading opencode v2 to 2.0.4, already-running TUI sessions that reconnect to the upgraded server show a false "Session location unavailable" prompt telling the user to "Choose another directory to continue this session" — even though the working directory never changed and is still valid. Following the prompt and trying to choose a directory then fails with Missing key at ["projectID"]. Quitting and reopening the session fixes everything.
The primary bug is the false prompt: the session's location is fine. It appears because protocol drift between the old in-process client and the new server breaks the post-reconnect location sync, and the TUI misreports that as "location unavailable".
Environment
- opencode version: 2.0.4 (latest channel; the affected sessions were started on a pre-2.0.4 build, 2.0.3)
- OS: Darwin 27.0.0 (macOS arm64)
- Terminal: ghostty (TERM=xterm-ghostty, COLORTERM=truecolor)
- Shell: fish
- Install/channel: latest
- Active plugins: none
Reproduction
- Start a TUI session on opencode 2.0.3 (managed server running).
- Upgrade opencode to 2.0.4 while the TUI session is still open, so the server restarts on the new version.
- The still-running 2.0.3 TUI reconnects to the 2.0.4 server.
- The session shows the recovery screen:
The directory is the same one the session has always used; it was never changed and remains valid.Session location unavailable <directory> Choose another directory to continue this session. - Select "Choose directory" as prompted. The Worktrees dialog fails:
Worktrees Could not load worktrees Missing key at ["projectID"] Close and reopen Worktrees to try again. - Closing and reopening the Worktrees dialog retries the same request and fails again. Quitting that opencode session and reopening it resolves everything.
Observed during the 2.0.4 upgrade; reproducible for every session that stayed open across the upgrade.
Expected Behavior
Reconnecting to an upgraded server should not claim the session's location is unavailable when the working directory is unchanged and valid. Either the running TUI should remain compatible with the upgraded server, or it should detect the client/server version mismatch and ask to restart — a protocol incompatibility should not be surfaced as "choose another directory".
Actual Behavior
After the upgrade reconnect, the TUI presents a false "Session location unavailable" recovery screen for a perfectly valid directory, and the recovery flow it offers is itself broken (Missing key at ["projectID"]), leaving no path forward except quitting opencode entirely.
Additional Context
Root cause is client/server version skew across the upgrade reconnect:
False prompt: on reconnect, LocationProvider (packages/tui/src/context/location.tsx) listens for server.connected and re-runs data.location.sync(), which fans out to ~13 location-scoped endpoints via Promise.all (packages/client/src/solid/data.ts: location.get, form, vcs, agent, command, integration, mcp, model, provider, reference, skill, shell…). Any single rejection sets error, which the session route renders as the "Session location unavailable" recovery screen. With a 2.0.3 client against a 2.0.4 server, several of these calls fail on protocol drift — e.g. the old client calls GET /api/form/request (form.request.list), which 2.0.4 renamed to GET /api/form (#48867 era protocol cleanup, packages/protocol/src/groups/form.ts), so the fan-out rejects even though location.get for that same directory succeeds. A failed fan-out should not be reported as "location unavailable".
Broken recovery picker: the recovery screen's Worktrees dialog calls GET /api/worktree, whose query changed in 2.0.4 from LocationQuery (location[directory]=…) to a required projectID (#48867 / 081eef3b80, "make worktree APIs project-based", in packages/protocol/src/groups/worktree.ts). The old client sends the 2.0.3 query shape, the server rejects it with the schema decode error, and the dialog surfaces the raw parse error (packages/tui/src/component/dialog-workspaces.tsx) whose only suggested remedy — close and reopen — retries the same incompatible request.
Why the skew is allowed: the still-running pre-2.0.4 TUI keeps its old in-process client SDK and reconnects through managedService.reconnect → Service.ensure with version: undefined (packages/cli/src/services/server-connection.ts), i.e. the version gate is disabled on reconnect, so the old TUI attaches to the new server with no mismatch handling.
Workaround: quit the affected opencode session(s) and reopen them so the relaunched TUI matches the server version.
Related: #48736 (same upgrade → location-unavailable → Worktrees-load failure pattern on 2.0.1 → 2.0.3, but error was UnexpectedStatus), #46322, #43415.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.