anomalyco / anomalyco/opencode

tui: false "Session location unavailable" prompt after upgrade reconnect

Open
#49,352 0 comments 0 reactions 1 assignee View on GitHub

@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

  1. Start a TUI session on opencode 2.0.3 (managed server running).
  2. Upgrade opencode to 2.0.4 while the TUI session is still open, so the server restarts on the new version.
  3. The still-running 2.0.3 TUI reconnects to the 2.0.4 server.
  4. The session shows the recovery screen:
    Session location unavailable
    <directory>
    Choose another directory to continue this session.
    
    The directory is the same one the session has always used; it was never changed and remains valid.
  5. 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.
    
  6. 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.reconnectService.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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.