Desktop silently loads cross-project data after project switch — data-integrity hazard, unfixed for 3 months, 15+ duplicates #35890

Description

This is a data-integrity defect, not a UX papercut.

OpenCode Desktop silently displays — and in documented cases operates on — the wrong project's data after switching projects. In #29714, the agent read and modified files in a different repository than the one the user selected, because both paths existed on disk. This is the class of bug that destroys work, and it is still reproducible today on v1.17.15.

It has been open since at least April 2026 with 15+ duplicates, and remains unfixed.

What happens (repro, v1.17.15, Windows, today)

1. Open project B, send a message, let it complete.
2. Switch to project A (different folder, no rename, no shared git identity).
3. Observe: project A's directory loads, but project B's notifications, last-session layout, and recently-closed entry bleed into A's view.

Root cause — stale references spread across SIX storage layers

I traced every location holding the bleed. No combination of manual cleanup is durable, because the running sidecar re-writes one of them on every tick.

A user in #31888 performed 58 base64 path replacements, merged workspace .dat files, cleared every Electron cache, and edited the SQLite DB — Desktop still loaded the old project and 503'd. I reproduced the same: cleanup is not durable.

Why it's still broken

The server compounds it. InstanceStore.load / fromDirectory resolve a non-existent directory to the global project instead of rejecting. So the client's stale cached path doesn't fail loudly — the server bootstraps a phantom instance for a folder that doesn't exist, then 503s on every subsequent call.

• PR fix(server): reject instance requests for non-existent directories #33309 (server-side 404 guard for non-existent directories) — not merged.
• [FEATURE]: Auto-relink stale sessions when project_id matches but directory is outdated #27822 (working SQL migration that auto-relinks stale sessions via the existing session.project_id → project.worktree relationship — OpenCode already has the data to self-heal)

Plugins

oh-my-openagent@latest (v4.16.0)

OpenCode version

1.17.15 (OpenCode Desktop, Windows)

Steps to reproduce

1. Open project B in OpenCode Desktop. Send a message and let the turn complete. Close/switch away from B.
2. Open project A — a different folder, not a rename, not a shared git identity.
3. Observe project A's directory loads, but project B's data bleeds in: activity notifications, the last-session page layout, and a recently-closed entry for B all render inside A's view.

Confirmed the bleed persists across these exact storage locations on disk:

• %APPDATA%/ai.opencode.desktop/opencode.global.dat → server.recentlyClosed.local[] still contains B's path
• same file → layout.page.lastProjectSession["<B's path>"] still set
• same file → notification.list[] contains entries with directory: <B's path>
• ~/.local/share/opencode/storage/oh-my-openagent/tui-state/*.json → projectDir = B's path, and it is re-written live by the running sidecar, so deleting it while the app runs has no effect.

Manual cleanup of these fields resolves the symptom temporarily, but is not durable — the sidecar rewrites layer 6, and the SQLite layer (opencode.db) cannot be safely purged while locked.

Screenshot and/or share link

(not attaching — sensitive project paths in the local data; the field names and storage locations above are verifiable on any affected install)

Operating System

Windows 11

Terminal

N/A — OpenCode Desktop app (Tauri/Electron GUI), not a terminal session