Skip to content

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

Closed as not planned
Closed as not planned
Desktop/WebUI: New sessions not shown in sidebar when connected to non-localhost server on same machine#19348
Assignees
adamdotdevin

Description

@attkri
attkri
opened on Mar 26, 2026

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.

Activity

  1. github-actions
    assigned
    adamdotdevin
    on Mar 26, 2026
  2. github-actions
    added
    webRelates to opencode on web / desktop
    windows
    on Mar 26, 2026

  3. github-actions commented on Mar 26, 2026

    @github-actions
    github-actionsBot
    on Mar 26, 2026 – with GitHub Actions
    Contributor

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

    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.

  4. attkri commented on Mar 27, 2026

    @attkri
    attkri
    on Mar 27, 2026
    Author

    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.

  5. attkri commented on Mar 27, 2026

    @attkri
    attkri
    on Mar 27, 2026
    Author

    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

  6. attkri commented on Mar 27, 2026

    @attkri
    attkri
    on Mar 27, 2026
    Author

    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

  7. attkri commented on Mar 27, 2026

    @attkri
    attkri
    on Mar 27, 2026
    Author

    Additional confirmed observation after the DB normalization:

    • The shared DB is still clean (session.directory now matches canonical project.worktree; mismatch verification stays at
  8. thdxr
    removed
    windows
    webRelates to opencode on web / desktop
    on May 3, 2026

  9. github-actions commented on Jul 5, 2026

    @github-actions
    github-actionsBot
    on Jul 5, 2026 – with GitHub Actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

  10. github-actions
    closed this as not plannedon Jul 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions