Skip to content

Desktop Home view shows projects but zero sessions (database is correct) #36064

New issue
New issue
Closed as not planned
Closed as not planned
Desktop Home view shows projects but zero sessions (database is correct)#36064
Assignees
kitlangton

Description

@DiasMazhenov
DiasMazhenov
opened on Jul 9, 2026

Desktop (GUI) Home view shows projects but zero sessions — database is correct

Summary

The OpenCode Desktop app (macOS) shows the list of projects in the Home / sidebar, but every project displays "Nothing here yet" / 0 sessions, even though the SQLite database contains correctly-linked sessions. The terminal opencode CLI reads and writes the exact same database without any problem.

Environment

  • OpenCode Desktop: 1.17.16 (also reproduced on earlier versions)
  • opencode CLI: 1.17.15
  • OS: macOS (darwin, arm64)
  • Database: ~/.local/share/opencode/opencode.db (~916 MB, 164 sessions, 5+ projects)

Observed behavior

  1. Open Desktop → Home view.
  2. Sidebar lists the 3 projects the user has added (e.g. opencode-settings-project, dockinkz, usage-widget).
  3. Selecting any project shows "Nothing here yet — Create a session to get started". No session is listed for ANY project.
  4. The terminal opencode CLI in the same projects works perfectly and its sessions are persisted to the DB.

Expected behavior

Sessions that exist in the database for a given project should appear in the Desktop Home view for that project.

Evidence that the data is correct (not a DB/config issue)

Verified directly against ~/.local/share/opencode/opencode.db:

  • session.project_id correctly references project.id (FK intact): 
    SELECT s.id, p.worktree, COUNT(*) FROM session s
JOIN project p ON p.id = s.project_id GROUP BY p.id;
-- /Users/diasmazhenov/vibecode/usage-widget | 3
-- /Users/diasmazhenov/vibecode/dockinkz       | 1
-- .../opencode-settings-project                | 1
  • session.directory matches project.worktree (fixed a mismatch, but the other projects already matched and still show 0).
  • session.time_archived is NULL for all relevant sessions.
  • session.workspace_id is NULL for all (consistent, not the cause).
  • workspace table is empty for everyone — not the differentiator.
  • The Desktop process holds the same shared DB file (confirmed via lsof: OpenCode … /Users/diasmazhenov/.local/share/opencode/opencode.db).
  • Other projects (/, open-design) that are NOT in the Desktop sidebar DO have many sessions in the DB (86 / 73), so the Desktop's project list is a curated subset — but the 3 it shows still render 0 sessions despite valid data.

Notes

  • The local Desktop API (http://127.0.0.1:<port>/project/:id/session) returns 401 Unauthorized (Basic realm) and the session list endpoint returns empty; the auth token could not be retrieved from local storage / process env, so the failure appears to be server-side session listing within the Desktop-embedded server rather than a pure frontend render issue.
  • A fresh restart of the Desktop app (which regenerates opencode.global.dat) does not resolve it.
  • opencode serve started manually also returns empty session lists for the same DB, suggesting the session-listing query/path used by the server is the failing component.

Impact

The Desktop GUI is effectively unusable for browsing/reopening past sessions; only the terminal CLI can access them.

Root-cause analysis (from source)

The Desktop Home session list pipeline:

  1. packages/app/src/pages/home.tsx → sessionLoad query calls
    focusedSync().project.loadSessions(directory, …) for each projectDirectories().

  2. packages/app/src/context/directory-sync.ts → fetch() calls client.session.list()
    (SDK client scoped to the project directory) and stores results in the sync store.

  3. buildHomeSessionRecords() (home.tsx:108) reads sync.child(directory)[0] and runs
    sortedRootSessions() → roots() → isRootVisibleSession().

  4. packages/app/src/pages/layout/helpers.ts:26:

    const isRootVisibleSession = (session, directory) =>
  pathKey(session.directory) === pathKey(directory) && !session.parentID && !session.time?.archived

The bug: isRootVisibleSession reads session.directory, but the OpenCode server's
GET /api/session response does NOT include a top-level directory field — the directory
is only present under location.directory:

{
  "id": "ses_xxx",
  "projectID": "…",
  "location": { "directory": "/Users/…/project" },
  "time": { "created": …, "updated": … }
}

So session.directory is undefined → pathKey(undefined) === pathKey(directory) is false →
every session is filtered out of the Home list. This matches the reported symptom exactly
(projects show, sessions never do, for all projects).

projectForSession() (helpers.ts:104) has the same problem: its directory fallback
pathKey(project.worktree) === pathKey(session.directory) also fails when session.directory
is undefined (only the projectID direct match works there).

Suggested fix

Either:

  • The server should return a top-level directory field on sessions (mirroring location.directory), or
  • The SDK/client Session type should map location.directory → directory before the UI consumes it.

Activity

  1. github-actions
    assigned
    kitlangton
    on Jul 9, 2026

  2. github-actions commented on Jul 9, 2026

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

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

  3. DiasMazhenov commented on Jul 9, 2026

    @DiasMazhenov
    DiasMazhenov
    on Jul 9, 2026
    Author

    Update from community report (forum): this is a Desktop cache/state restoration bug, not a storage or directory-mapping issue.

    A user confirmed that clearing only the Desktop UI/cache state restored session visibility immediately:

    ~/.config/ai.opencode.desktop/opencode.global.dat
~/.config/ai.opencode.desktop/opencode.workspace.*.dat

    (macOS equivalent: ~/Library/Application Support/ai.opencode.desktop/)

    After removing those files and restarting Desktop, the full session list reappeared. CLI and TUI could always see all sessions. Symlink vs realpath may be a trigger but was not the root cause in that case.

    So the failure is in Desktop's cached session-list index / state restoration going stale and not re-indexing from the DB — not in session persistence. The earlier hypothesis about session.directory vs location.directory does not hold (clearing cache fixes it without any data change).

  4. JohnRen325 commented on Jul 11, 2026

    @JohnRen325
    JohnRen325
    on Jul 11, 2026

    Additional data point: cross-version DB, cache-clear does NOT fix, write-touch does

    Environment: DB authored by Desktop v1.14, opened/read by CLI v1.17, Desktop v1.14→v1.17, Windows (%APPDATA%\ai.opencode.desktop\).

    Observed

    1. After a v1.14-authored opencode.db was read by CLI v1.17, the Desktop sidebar showed 1 sessions for every project, while the CLI listed them all from the same file.
    2. Upgrading Desktop to v1.17 did not help.
    3. Deleting opencode.global.dat + opencode.workspace.*.dat and restarting did NOT help either — so for this case it is not a stale UI-cache issue.

    Workaround (reliable)

    1. Open CLI (it sees all historical sessions).
    2. In each session, submit any prompt (such as "hello") — no model response needed, immediately ESC-interrupt it.
    3. Quit CLI, restart Desktop, open the project → submitted sessions reappear.

  5. Giblarium commented on Aug 14, 2026

    @Giblarium
    Giblarium
    on Aug 14, 2026

    Additional data point for Windows: drive-letter case mismatch between the Desktop layout store and the DB hides all sessions in Home.

    Environment

    • OS: Windows 11
    • OpenCode Desktop: 1.18.18 (also reproduced on 1.18.7 CLI)
    • DB: C:\Users\<user>\.local\share\opencode\opencode.db

    Observed

    Projects show in Home, but every project renders zero sessions — same as the original report. The terminal CLI lists all sessions from the same DB without issue. Clearing the Desktop UI cache (.dat files, Local Storage) did not help; "write-touch" via CLI did not help either.

    Root cause found

    The persisted Desktop layout store (opencode.global.dat, key server.projects) stores the project worktree with a lowercase drive letter:

    "worktree":"d:\Users\ilsch\Documents\OpenCode\oneS"

    while the database stores session.directory / project.worktree with an uppercase drive letter:

    D:/Users/ilsch/Documents/OpenCode/oneS

    The Home pipeline (buildHomeSessionRecords -> pathKey) compares pathKey(session.directory) against pathKey(project.worktree) from the layout store. pathKey only normalizes slashes (\ -> /) and does not normalize drive-letter case, so on Windows:

    pathKey("D:/Users/.../oneS") !== pathKey("d:/Users/.../oneS")

    Every session is filtered out -> "zero sessions" for every project. This matches the symptom exactly and is the same path-sensitivity class as #14570 / #17518, but on the Home/Desktop layout store side.

    Workaround (confirmed working)

    Align the DB paths to the layout's drive-letter case (lowercase), then fully restart Desktop:

    UPDATE session          SET directory = lower(directory);
UPDATE project          SET worktree  = lower(worktree);
UPDATE project_directory SET directory = lower(directory);

    (or, alternatively, normalize the persisted layout worktree to uppercase — the two stores must match case-wise).

    Suggested fix

    Make path comparison on Windows case-insensitive in pathKey (normalize drive letter and ideally compare case-insensitively), or canonicalize paths to a single form when persisting to the layout store vs. writing to the DB.

  6. thdxr commented on Oct 11, 2026

    @thdxr
    thdxr
    on Oct 11, 2026
    Member

    Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

    — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

  7. thdxr
    closed this as not plannedon Oct 11, 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