[Web UI] Sessions under workspace root are missing after upgrading to 1.2.21

[singularity2000]

Describe the bug

After upgrading to OpenCode 1.2.21, the Web UI no longer shows sessions when I open it from my workspace root directory on Windows.

In that directory context, the sidebar is effectively empty: the expected session list is missing, and the usual New Session action is also not shown.

This worked before the upgrade.

To reproduce

1. Use a workspace root directory on Windows that already has historical OpenCode sessions.
2. Start opencode web from that workspace root.
3. Open the Web UI.
4. Enter that workspace-root context.

Expected behavior

The sidebar should either:

• show the existing root sessions for that directory, or
• show a normal empty state with a visible New Session action.

Actual behavior

• The sidebar does not show the expected session list.
• The New Session action is also missing in that context.
• The rest of the page still renders.

Environment

• OpenCode: 1.2.21
• Also reproducible on: 1.2.22
• OS: Windows
• Launch directory pattern: E:\AI\...\Opencode\workspace
• Local Web UI: http://127.0.0.1:4096

Additional context

I checked the local database and the sessions still exist.

• SQLite integrity check returns ok
• The workspace root still has about 30 sessions in the database
• 16 of them are root sessions (parent_id IS NULL)
• But the Web API call below returns an empty list for the same directory:
  • GET /session?directory=<workspace_root>&roots=true&limit=55
  • response: []

This looks like a regression in session scoping/filtering rather than database corruption.

It may be related to older sessions under the workspace root being associated with project_id = global and no longer being returned by the Web UI query after the upgrade.

This may also be related to #14570, but in my case it is consistently reproducible from a workspace-root launch on Windows.

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• This issue was not submitted using one of the required issue templates (Bug Report, Feature Request, or Question). Please resubmit using the appropriate template.
• The issue body appears to be AI-generated (it explicitly states so), which is not acceptable per our guidelines. Please provide a concise, human-written description of the problem.
• The issue is excessively long with duplicated content in two languages. Please keep the report focused and concise.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

This issue might be a duplicate of existing issues. Please check:

• [BUG][Windows][Web/Desktop] Session sidebar uses path-sensitive exact matching (slash + drive-case), causing hidden sessions and duplicate workspaces #14570: Same symptoms on Windows — session sidebar empty despite sessions existing in DB, related to path/directory matching and project_id = global sessions not being returned by the Web API

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

Thank you for updating the issue! It now follows the contributing guidelines and includes all the required information. We appreciate you taking the time to revise it.

[attkri]

Additional findings: v1.2.21 regression confirmed with full isolation test

Environment

• OS: Windows 11 (10.0.26200.8037)
• Affected versions: v1.2.21 through v1.2.27 (Desktop + CLI serve)
• Working version: v1.2.20
• Database: 530 MB, 728 sessions, 26170 messages, 87586 parts — PRAGMA integrity_check returns ok

Isolation test (rules out data/cache corruption)

Created a fresh Windows user, ran opencode.exe serve --port 4098 from a clean directory. Fresh database migration completed. Accessed via Chrome (both normal and separate Chrome user profile).

Result: Sidebar session list is empty even with a brand-new database containing only 1 session. The session content area renders fine (can create and view sessions), but the sidebar never populates the session list. This rules out database corruption, Electron cache, or user-specific data as the root cause.

Root cause: commit b0bc3d87 in v1.2.21

The regression was introduced by commit b0bc3d87 ("feat(app): sidebar reveal animation, hover peek overlay, and weaker dividers"), which changed +162/-38 lines in packages/app/src/pages/layout.tsx — the exact file identified in #16837 as the location of the broken createEffect logic.

This commit is part of v1.2.21 (Mar 7, 2026). v1.2.20 does not have this change and works correctly.

Backend API works fine

Both the v1.2.20 and v1.2.27 servers return identical session data from the API:

curl -s http://127.0.0.1:4096/session → 100 sessions (JSON array, 61 KB)
curl -s http://127.0.0.1:4097/session → identical 100 sessions

The backend is not the issue. The SolidJS frontend fails to render the session list.

Additional finding: mixed path separators in database

The database contains sessions with both path formats:

• 670 sessions with forward slashes: C:/Users/.../OpCo-Know
• 58 sessions with backslashes: C:\Users\...\OpCo-Know

The v1.2.27 Desktop app encodes workspace URLs with backslashes (QzpcVXNlcnNc... → C:\Users\...), while v1.2.20 uses forward slashes (QzovVXNlcnMv... → C:/Users/...). This path inconsistency may contribute to session filtering failures.

Related issues

This appears to be the same underlying bug as #16837, #16562, #16864, #17291, #17622, and #17765 (filed today with the same symptoms on Windows).

[attkri]

Second finding: path separator mismatch in session.directory causes session loss on Windows

In addition to the frontend autoselect bug, there is a separate backend/database issue that causes sessions to be invisible depending on which server version created them.

The problem

The session.directory column contains mixed path separators:

SELECT
  CASE WHEN directory LIKE '%/%' AND directory LIKE 'C:/%' THEN 'forward-slash' ELSE 'backslash' END AS type,
  COUNT(*) AS count
FROM session GROUP BY type;

-- Result:
-- forward-slash | 670
-- backslash     |  58

Sessions created by v1.2.20 and earlier store directories with forward slashes (C:/Users/.../OpCo-Know).
Sessions created by v1.2.21+ store directories with backslashes (C:\Users\...\OpCo-Know).

Impact

Both server versions filter sessions using a strict string match on directory:

GET /session?directory=C%3A%2FUsers%2F...  → 12 sessions (forward-slash match)
GET /session?directory=C%3A%5CUsers%5C...  →  3 sessions (backslash match)

This is identical on both v1.2.20 and v1.2.27 servers — neither normalizes paths in the query.

The v1.2.27 Desktop/server resolves the current project directory with backslashes (Windows native), so it only finds the 58 sessions created by v1.2.27. The 670 older sessions (forward-slash paths) are invisible.

Verified in the Desktop app

Same project (OpCo Know, same project_id), same database, same Desktop app (v1.2.27):

Connected to	Project path shown	Sessions visible
v1.2.20 server	C:/Users/Projects/OpCo-Know	All sessions (forward-slash matches)
v1.2.27 server	~\Projects\OpCo-Know	Only 3 new sessions (backslash matches)
Local v1.2.27	~\Projects\OpCo-Know	Only 3 new sessions (backslash matches)

Root cause

The path format change was likely introduced by v1.2.25's "Normalize backslash paths in config rel() and file ignore on Windows" and related Windows path canonicalization changes in v1.2.11/v1.2.21. New sessions are correctly written with native Windows backslashes, but the query layer doesn't account for old sessions stored with forward slashes.

Suggested fix

The session query should normalize path separators before matching, e.g.:

WHERE REPLACE(directory, '/', '\') = REPLACE(?, '/', '\')

Or normalize all existing directory values during a migration:

UPDATE session SET directory = REPLACE(directory, '/', '\') WHERE directory LIKE 'C:/%';

Note: This is a separate issue from the frontend autoselect bug (PR #16838). Both need to be fixed for sessions to work correctly on Windows with v1.2.21+.

[babblinbijou]

After upgrading from v1.2.27 → v1.3.2 on macOS, experienced same issue. 8 of 14 sessions invisible in session list despite existing in DB with project_id pointing to my workspace.

Workaround found: Export then re-import each session:

opencode export <session_id> > session.json
opencode import session.json

After import, sessions appear in session list. The import apparently creates missing workspace entries that the upgrade failed to create.

This may help diagnose - perhaps the workspace migration doesn't create entries for existing sessions when upgrading from versions that predate the workspace feature.