Repository navigation
References to a deleted session outlive it: address bar, recent-tab pointer and persisted handoff #47683
Description
Description
Deleting a session leaves three references behind, each pointing at something that no longer
exists. They share one cause, so they are filed together.
The deleted session stays in the address bar. In removeSessions
(packages/app/src/context/tabs.tsx) the current-tab check is gated on params.dir:
const currentHref =
targetServer === server.key && params.dir && params.id ? tabHref({ ... }) : undefinedparams.dir only exists on the legacy /:dir/session/:id route. On
/server/:serverKey/session/:id there is no directory, so currentHref stays undefined,
removedCurrent stays false, and the navigation to the next tab never runs. tabHref builds from
server and session id alone and does not need the directory.
The recent-tab pointer survives. It is only cleared when the removed session still had an open
tab (if (recent.key && removed.includes(recent.key))). The pointer is persisted separately and
outlives the tab, so deleting a session that had already been closed leaves it aimed at the deleted
id.
The persisted layout handoff survives. It carries a session id across a layout switch
(store.handoff.tabs in packages/app/src/context/layout.tsx) and nothing clears it on deletion,
so later starts try to restore a session that is gone.
Fallout. When the app then resolves that id, current() throws. The two effects that read it —
LegacyTargetSessionRedirect in packages/app/src/app.tsx and ResolvedTargetSessionRoute in
packages/app/src/pages/session.tsx — throw from inside an effect. Solid's ErrorBoundary only
catches throws during render, so this passes the scoped SessionRouteErrorBoundary (which would
show the "not found" page) and reaches the global one, replacing the whole window with "something
went wrong" for a chat that was merely deleted.
Plugins
None
OpenCode version
dev (ea2d59d)
Steps to reproduce
- Open a session on
/server/:serverKey/session/:id. - Delete that session.
- The URL still points at it and the view keeps trying to load it.
- Restart the app — the persisted handoff restores the deleted session, and the global error
boundary replaces the window.
Screenshot and/or share link
N/A
Operating System
Windows 11 (26200)
Activity
github-actions commentedon Sep 6, 2026
This issue might be a duplicate of existing issues. Please check:
lastProjectSessionreferences a session missing fromopencode.db— also covers stale session pointers surviving deletion and causing fatal crashes on next launch.Your report adds useful detail (the
removeSessionsroute-param guard bug and the recent-tab pointer not being cleared), so it may still be worth keeping open as a broader umbrella for all three reference sites, but please review the linked issues to avoid duplicated effort.opencodejr commentedon Oct 28, 2026
Thanks for the detailed write-up. I tried this on the commit you reported (
ea2d59d7ca) and on the latestdev(b6c43a52), in the web app with its end-to-end test setup and a mock server. I couldn't reproduce it:ea2d59d7ca, deleting the open session on/server/:serverKey/session/:idfrom the session header's menu moved the URL to the next session. The header's delete action navigates away by itself, so theparams.dircheck inremoveSessionsdoesn't matter on that path. On currentdev,removeSessionsno longer checksparams.dir, and the existing tab test that deletes the current session passes: the URL moves to the next tab.store.handoff.tabs/context/layout.tsxno longer exist on currentdev, and I couldn't test the restart path.If you still see this, could you share:
opencodejr commentedon Oct 31, 2026
Closing this for now. I couldn't reproduce it on
ea2d59d7caor on the latestdev(b6c43a52). Deleting the open session moved the URL to the next session. Opening a deleted session showed the "This session cannot be found" page with a Close Tab button, not the global error page. We haven't heard back about which app you use (desktop or web), how you deleted the session, or what the error page showed.If it still happens on a current build, please reply with those details or open a new issue that links back to this one (#47683), and we'll take another look. Thanks for the detailed report.