Skip to content

Desktop renderer fatally crashes (404 NotFoundError) when lastProjectSession references a session missing from opencode.db #32473

Closed as not planned
Closed as not planned
Desktop renderer fatally crashes (404 NotFoundError) when lastProjectSession references a session missing from opencode.db#32473
Assignees
Hona

Description

@andymina
andymina
opened on Jun 15, 2026

Summary

On the desktop app, if the persisted lastProjectSession pointer for a project references a session ID that no longer exists in opencode.db, the renderer throws an unhandled NotFoundError (HTTP 404) and fatally crashes the entire window on launch. A missing session should degrade gracefully to an empty/new session instead of taking down the renderer.

This appears to be the SQLite-backed, desktop-renderer manifestation of the older file-storage bug in #12889 / #7773 (which on those versions only logged to stderr). On 1.17.7 it is a hard crash.

Environment

  • OpenCode Desktop 1.17.7 (ai.opencode.desktop)
  • Electron 42.3.3 / Chrome 148 / Node 24.15.0
  • macOS (arm64)
  • Storage: SQLite (~/.local/share/opencode/opencode.db)

What happens

  1. App launches and restores the last-open session for a project from ~/Library/Application Support/ai.opencode.desktop/opencode.global.dat (layout.page.lastProjectSession[<projectDir>].id).
  2. That session ID is not present in the session table of opencode.db.
  3. The renderer's session fetch returns 404; the error is not caught and the window crashes.

Error / stack (renderer.log)

fatal renderer error: Error: Session not found: ses_XXXXXXXXXXXX
    at wrapClientError (oc://renderer/assets/main-*.js)
    at request (oc://renderer/assets/main-*.js)
    at async retry (oc://renderer/assets/main-*.js)
    at async Promise.all (index 0)
Caused by:
{ "body": { "name": "NotFoundError",
            "data": { "message": "Session not found: ses_XXXX" } },
  "status": 404 }

How a pointer goes stale (repro)

  • The session referenced by lastProjectSession is deleted from opencode.db, or is a stub that was never committed (e.g. a session created moments before a prior crash, so global.dat records the ID but the DB row never lands).
  • Minimal repro: set lastProjectSession[<project>].id in global.dat to any session ID not in opencode.db, launch the app, open that project → crash.

Cascade behavior

This is self-sustaining: a crash persists the in-flight (un-committed) session ID into global.dat, so the next launch restores it and crashes again. The loop only breaks once the user manually lands on a session that does persist. Heavy multi-session workloads (e.g. orchestration plugins spawning many sessions) make stale pointers far more likely.

Expected

A 404 / NotFoundError while restoring lastProjectSession should be caught and treated as "no session" — open the project with an empty/new session — not crash the renderer.

Related

Activity

  1. github-actions
    assigned
    Hona
    on Jun 15, 2026

  2. github-actions commented on Jun 15, 2026

    @github-actions
    github-actionsBot
    on Jun 15, 2026 – with GitHub Actions
    Contributor

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

  3. jjserenity commented on Jun 28, 2026

    @jjserenity
    jjserenity
    on Jun 28, 2026

    Same error on Windows 11, OpenCode Desktop 1.17.11:

    Error: Session not found: ses_0f487e4adffeSyriIW2HvZtM2h
    at wrapClientError (oc://renderer/assets/main-D_cwiNV1.js:70469:12)
    at request (oc://renderer/assets/main-D_cwiNV1.js:65536:28)

    Confirmed the session ID is not present in ~/.local/share/opencode/opencode.db. The crash happens on startup when the desktop app tries to restore a stale lastProjectSession tab. After restart the same tab reappears and crashes again, forming a loop. Had to manually clear the persisted tab state to recover.

  4. jjserenity commented on Jun 28, 2026

    @jjserenity
    jjserenity
    on Jun 28, 2026

    A bit more detail on the code path for the maintainers:

    The crash originates in packages/app/src/app.tsx around lines 137-139 in ResolvedTargetSessionRoute:

    sync.session.lineage.resolve(id).catch((error) => {
  if (isSessionNotFoundError(error, id)) tabs.removeSessionTab({ server, sessionId: id })
  throw error   // <-- re-throws, causing the resource to go into errored state
})

    The handler correctly detects the SessionNotFoundError and removes the stale tab, but then re-throws the error. This causes the resolved resource to remain in an "errored" state, and the fallback ErrorPage is rendered instead of gracefully falling through.

    Meanwhile, the tab removal propagates back to the persisted store (default.dat / opencode.global.dat), so the stale session ID is eventually cleaned up — but the user still sees an error page on the current view.

    PR #32085 fixes a similar issue in directory-sync.ts, but this app.tsx path also needs the same treatment: after removeSessionTab, the error should not be re-thrown, or the route should redirect to a safe default (e.g., new session or project view).

  5. jjserenity commented on Jun 28, 2026

    @jjserenity
    jjserenity
    on Jun 28, 2026

    Another data point: the same stale session problem also applies to the "tabs" array in opencode.global.dat. On my machine, all 3 persisted session tabs were stale. After removing the first stale tab and restarting, closing the remaining tab caused a cascade - the app tried to switch to the next stale tab in the list and crashed again with the same Session not found error. Only after clearing all stale entries from "tabs" did the app behave normally.

    So the persisted session tab list is another vector for this bug, not just lastProjectSession. A fix should handle stale session IDs anywhere they're stored: lastProjectSession, "tabs", and possibly sessionTabs in the layout state.

  6. ZYMCao commented on Jun 29, 2026

    @ZYMCao
    ZYMCao
    on Jun 29, 2026

    I encountered this very issue as well.

  7. Meepo268 commented on Jul 9, 2026

    @Meepo268
    Meepo268
    on Jul 9, 2026

    win11也遇到这个问题，目前我找到的解决办法是，手动设置默认服务器，

  8. Nasnl commented on Aug 22, 2026

    @Nasnl
    Nasnl
    on Aug 22, 2026

    I have the same thing, and it causes many error notifications when starting OpenCode desktop; that keeps going on for 3-4 minutes, and only then I can use the desktop.

  9. 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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

  10. 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