Sessions disappear after renaming project folder - directory matching is case-sensitive with inconsistently normalized stored paths

[jvirkel]

Description

Environment

• OpenCode desktop app 1.18.18
• Windows 10 22H2 (build 19045)

Steps to reproduce

1. Create sessions in a project folder (e.g. D:\Documents\Default Project)
2. Rename that folder to something else (e.g. D:\Documents\OpenCode)
3. Open the app on the renamed folder -> session list is empty
4. Rename the folder back -> sessions still do not appear reliably

Expected behavior

Renaming a project folder should not orphan its sessions. Windows paths are
case-insensitive, so d: and D: must be treated as identical.

Actual behavior / root cause

Session listing filters by exact string comparison:

listByProject() in packages/opencode/src/session/session.ts does
eq(SessionTable.directory, input.directory) — case-sensitive SQLite match.

Meanwhile, stored session.directory values are normalized inconsistently.
Found in the same database, created by opencode itself:

• D:/Documents/Default Project
• d:/Documents/Default Project <-- lowercase drive letter

The desktop app also stores the registered project as d:\\Documents\\OpenCode
(lowercase) in its state file, while other components use uppercase. So even
after manually updating all DB paths to the "correct" casing shown by Explorer,
/api/session?directory=D:\Documents\OpenCode returned 6 sessions but the UI
requested d:\Documents\OpenCode and got 0.

The event-sourced payloads (event table, type session.created/updated)
also embed the old directory path inside their JSON, which kept stale paths
alive after fixing the session table.

Data loss appearance

Nothing was actually lost (messages live in the global opencode.db), but from
the user's perspective ALL sessions vanish after a folder rename, which looks
catastrophic.

Suggested fix

Resolve both sides to a canonical real path (e.g. via realpath) before storing
and before comparing, or compare case-insensitively on Windows.

Workaround used

Directly updated opencode.db: session.directory, session.path and every
JSON directory field inside the event table, matching the exact casing the
app sends (d:\Documents\OpenCode). Sessions reappeared after app restart.

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

[github-actions]

This issue might be a duplicate of or closely related to existing issues. Please check:

• Session paths split by casing on case-insensitive macOS volumes #44014: Same case-sensitivity bug on case-insensitive macOS APFS volumes — stored path casing diverges from the lookup casing, causing sessions to vanish.
• [FEATURE]: Allow renaming/moving a project folder while persisting session history (replacement for stale-closed #25625) #44256: Feature request specifically for persisting session history across project folder renames/moves (directly covers the same symptom described here).
• Stale project paths in localStorage cause frontend to jump to non-existent directory, hiding new sessions #44073: Related report about stale project paths causing sessions to disappear after a folder is renamed/moved (frontend caching + backend ENOENT on startup).

[neohiro]

Independent confirmation from a real affected install (Windows 11): I found stored directory values differing only by drive-letter case created days apart by opencode itself, matching your report. Also worth noting for the fix: beyond casing, the same lookup breaks entirely after renames/moves (#23248), and paths inside event payloads are JSON-escaped inconsistently (one and two levels). A canonical real-path comparison would solve the case issue but not the rename one — treating them as one normalization+relink problem is probably the cleaner target. Working on a proposal, will cross-link.

[neohiro]

PR is up: #45133 - it covers the relink/migration half of this (rename+move, all stored encodings) plus groundwork docs for the delete-cascade and Desktop registry cleanup. Feedback welcome.