Desktop beta stops showing sessions until UI state files are cleared #28477

Activity

1. github-actions

   assigned

   Hona

   on May 20, 2026
2. github-actions commented on May 20, 2026

   

   github-actionsBot

   on May 20, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Bug: Desktop session save failure caused by corrupted opencode.global.dat index #20450: Very similar — Desktop session save failure caused by corrupted opencode.global.dat index, with the same workaround of clearing the .dat files to restore sessions
   • Desktop/Windows: newly opened project has sessions in SQLite but missing history/sidebar because opencode.global.dat is not updated #26207: Related (now closed) — Desktop sidebar missing sessions because opencode.global.dat is out of sync with actual session storage, same root cause

   If your issue is distinct from those (e.g., specific to a symlink vs. realpath triggering the desync), please add details clarifying the difference.
3. Keesan12 commented on May 20, 2026

   

   Keesan12

   on May 20, 2026

   More actions

   When clearing UI state files fixes missing sessions, that usually means the source of truth and the view cache disagree about ownership or versioning.

   I would look for a cache schema/version receipt on startup: discovered sessions, cached session index version, migration result, and why any entry was filtered. Otherwise users only learn that "deleting state works," not which persistence boundary actually broke.
4. jurkech commented on May 20, 2026

   

   jurkech

   on May 20, 2026

   Author

   More actions

   I can confirm this was not a storage failure.

   CLI could still see all sessions, including sessions originally created in Desktop. Clearing only the Desktop UI/cache state restored visibility immediately:

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

   After removing those files and restarting Desktop, the session list reappeared.

   I also checked the symlink angle more closely. My repo is available through both:

   • /home/roman/archive/work/tests/erm-playwright-tests
   • /home/roman/work/tests/erm-playwright-tests

   CLI showed the same sessions from both paths, so core project/session storage seems to be resolving that correctly. That makes me think the main failure is in Desktop cache/state restoration or session-list indexing, not in the underlying session persistence itself.

   So symlink vs realpath may still be a trigger, but it does not look like the root storage identity problem in my case.
5. Keesan12 commented on May 21, 2026

   

   Keesan12

   on May 21, 2026

   More actions

   That extra detail helps a lot because it narrows the fault line to Desktop cache/index restoration instead of core session storage. The next receipt I would want on startup is: discovered sessions from source, cache index entries loaded, canonical workspace identity chosen, and filter reason for every hidden entry. Once those four numbers exist, you can usually tell in one boot whether the problem is stale cache, path canonicalization, or a bad migration instead of asking users to delete state files blindly.
6. Keesan12 commented on May 22, 2026

   

   Keesan12

   on May 22, 2026

   More actions

   A desktop-state receipt here would be more useful than deeper speculation: cache/index path, expected version, actual version, whether rebuild was attempted, and what made the app trust or reject the local state. That gives people a clean triage branch before they start deleting files blindly.
7. github-actions commented on Jul 22, 2026

   

   github-actionsBot

   on Jul 22, 2026 – with GitHub Actions

   Contributor

   More actions

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

   closed this as not plannedon Jul 22, 2026