Desktop/WebUI: New sessions not shown in sidebar when connected to non-localhost server on same machine

[attkri]

Bug

When using OpenCode Desktop or WebUI connected to a server running on 192.168.0.101:4096 (same machine, not remote), newly created sessions never appear in the left sidebar under that server context. They appear under Lokaler Server instead.

The same applies to opencode import — imported sessions only appear under the local server context, never under the selected non-localhost server.

Environment

• OpenCode v1.3.3
• Windows 11
• Server started via opencode serve on same machine, listening on 192.168.0.101:4096
• Desktop and WebUI both affected

Reproduction

1. Start opencode serve (listening on 192.168.0.101:4096)
2. Open Desktop or WebUI, select server 192.168.0.101:4096
3. Open project (e.g. OpCo-Know)
4. Click Neue Sitzung (New Session)
5. Session appears under Lokaler Server, not under 192.168.0.101:4096

Proof: API has the data, sidebar does not

Session ses_2d38a1958ffeXt6arU4hI359Qb created while 192.168.0.101:4096 was selected:

API returns the session:

GET http://192.168.0.101:4096/session/ses_2d38a1958ffeXt6arU4hI359Qb → 200 OK

API returns sessions for the project (verified via browser DevTools console):

GET /session?directory=C%3A%5CUsers%5Cattila%5CProjects%5COpCo-Know&roots=true&limit=55
→ COUNT 4

Sidebar for same project on same server: empty (0 sessions shown)

Same session under Lokaler Server: visible in sidebar

Additional evidence

• localStorage.clear() + reload does not fix it
• opencode import <file> also only lands in local server context
• Both server contexts run on the same machine, same user, same DB file
• The session row in DB has identical project_id, directory, parent_id=null as other visible sessions
• This is not a display/cache issue — it persists across reloads and localStorage.clear()

Expected

Sessions created while 192.168.0.101:4096 is selected should appear in the sidebar under that server context.

Actual

Sessions always land under Lokaler Server regardless of which server is selected. The user effectively cannot work with the non-localhost server because no sessions are ever shown there, despite the API confirming they exist.

[github-actions]

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

• [BUG]: Two remote servers with same directory path show identical session list in sidebar #17451: Sessions are keyed only by directory path with no server identity component — same root cause as described here
• Multi-server: layout state not namespaced per server causes session loop after switching #18302: Layout state not namespaced per server causes stale state and missing sessions when switching between servers
• Remote server responses not updating in desktop app when multiple servers are configured #17654: Remote server responses/sessions not updating in desktop app when multiple servers are configured

These issues describe the same underlying problem: the frontend does not include server origin in its state keys, so sessions created on a non-localhost server are associated with the local server context instead.

[attkri]

I checked the suggested related issues (#17451, #18302, #17654). They look adjacent, but they do not fully explain this case.

Why this is different:

• The failure already reproduces at the API layer on the server itself, before Desktop/WebUI state can misrender anything.
• includes the project (, )
• returns
• returns

• But returns the session correctly, with:

Database evidence from the shared SQLite DB:

• sessions exist with
• sessions exist with

There is also mixed directory formatting in the DB for the same project:

• -> 14 sessions
• -> 9 sessions
• plus a few mis-scoped entries under parent directories

So this looks broader than a pure frontend state collision:

• is related conceptually (frontend state keyed by directory only), but here the server's own endpoint already returns an empty list.
• is about stale layout/session restore state after switching servers; that does not explain .
• is about response rendering / live updates, not session listing.

The likely backend-side issue is that is being scoped to the wrong project context () and/or over-filtered by strict directory matching:

• adds
• resolves the instance from
• mixed slash formats ( vs ) make strict directory equality even more fragile

So I would currently classify this as related to #17451, but not a clean duplicate of #18302 or #17654.

[attkri]

New evidence from today: this is not a pure session created on the wrong server problem.

I attached the TUI directly to the 4096 server and created a brand new session in Lara47.

Command used:
opencode attach http://192.168.0.101:4096 --dir C:\Users\attila\Projects\Lara47\

Then I verified the result against the 4096 API itself.

The 4096 server does return the new Lara47 session correctly:

• GET /session?directory=C:\Users\attila\Projects\Lara47&roots=true&limit=10
• includes session ses_2d158eabdffeYZbiLQsZneCu46
• projectID = e06f5f1373bbadc24eac6873ebd27550f5092612
• directory = C:\Users\attila\Projects\Lara47

So for this reproduction, the session is definitely created on and listed by the 4096 server.

But in Desktop, the same session still only appears under Lokaler Server, not under the 192.168.0.101:4096 sidebar.

That means at least this Lara47 reproduction is much closer to #17451 and #18302 territory:

• server-side creation is correct
• server-side listing is correct
• the failure is in Desktop or WebUI server-context isolation or sidebar state, where server plus directory is apparently not being separated cleanly

So my current reading is:

• there may still be an additional project-scoping or path-normalization problem in some repos, for example OpCo-Know had earlier API-level oddities
• but this new Lara47 attach reproduction is a clean proof that one important failure mode is client-side server-context collision, not session creation on the wrong server

[attkri]

Final confirmed finding:

We normalized the shared SQLite session data so that session.directory now always matches the canonical project.worktree.

What we changed:

• First fixed Lara47
• Then fixed OpCo-Know
• Then ran a safe global normalization pass for all projects where the mismatch was slash-only (C:/... vs C:...) and one final cleanup for an old moved project path

Backups created:

• opencode.db.before-lara47-path-normalize.20260327-115533.bak
• opencode.db.before-opcoknow-path-normalize.20260327-124412.bak
• opencode.db.before-global-safe-path-normalize.20260327-133604.bak
• opencode.db.before-final-project-path-cleanup.20260327-133728.bak

Current DB state:

• no remaining non-canonical session.directory values relative to project.worktree
• verification query now returns

[attkri]

Additional confirmed observation after the DB normalization:

• The shared DB is still clean (session.directory now matches canonical project.worktree; mismatch verification stays at