[Bug]: Deleting a thread leaves its preview sessions in PreviewManager for the life of the server #14966
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Open one or more browser preview tabs on a thread (
preview.open). - Delete the thread without closing the tabs.
- Inspect
PreviewManager's session state, or repeat many times and watch server memory.
Expected behavior
Deleting a thread closes its preview sessions, the same way thread deletion already closes the thread's terminals and stops its provider session.
Actual behavior
The deleted thread's preview sessions stay in PreviewManager for the life of the server.
PreviewManager.openalways mints a fresh server-side tab id (apps/server/src/preview/Manager.ts:219) and inserts a new session (:239). The only removal is the explicitclose(:379, delete at:393).ThreadDeletionReactor.processThreadDeleted(apps/server/src/orchestration/Layers/ThreadDeletionReactor.ts:60-66) calls onlystopProviderSessionandcloseThreadTerminals. Nothing touches previews.PreviewManageris a server-lifetime layer, so these entries, each holding a snapshot, accumulate as threads are deleted.
Because the tab id is server-minted, a client cannot avoid the growth by reusing ids; only a server-side sweep can.
Impact
Minor bug or occasional failure
Version or commit
main @ c0995d2
Environment
Linux; found by code reading and reproduced in a fork (T3o).
Logs or stack traces
No response
Workaround
Close preview tabs before deleting a thread.
A reference fix from our fork: f33db3c. ThreadDeletionReactor closes every preview session for the deleted threadId alongside the terminal close, with a test in ThreadDeletionReactor.test.ts.
Activity
juliusmarminge commentedon Oct 3, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks for the detailed report, @samkelly880. We reproduced it on current
main. When you delete a thread, its provider session stops and its terminals close, but its preview sessions stay inPreviewManageruntil the server exits.What changed since the report: the
ThreadDeletionReactorpath you cited no longer exists. Orchestration v2 replaced it withplanThreadDeletioninapps/server/src/orchestration-v2/ThreadDeletion.ts, which queuesprovider-session.detach,terminal.cleanup, andattachment.cleanup. None of those touch previews. Deleting a project goes through the same plan, so all of its threads' preview sessions are left behind too, and archiving a thread doesn't clean them up either. These sessions only live in memory, so a restart clears them. Your fork commit patches the removed reactor, so it won't apply as-is.Server side:
apps/server/src/preview/Manager.tsstill behaves the way you described. Sessions live for the whole server process and are only removed byclose.close({ threadId })without atabIdalready drops every session for a thread, but the delete path never calls it. The fix is probably a preview cleanup effect queued next toterminal.cleanup.Desktop side: cleaning up on the server isn't enough by itself.
deleteThreadinapps/web/src/hooks/useThreadActions.tscloses terminals but not previews. The preview atoms are keep-alive, andElectronBrowserHostkeeps a Chromium guest running for every session in them.usePreviewSessiononly handles the server'sclosedevent while that thread's preview view is on screen, and deleting a thread navigates away right away. So the web client also needs to close the thread's previews.Workaround: close the thread's preview tabs before deleting it. That frees both the server sessions and the desktop guests.
We didn't find an existing issue for this. The open PR #14955 handles the opposite problem: tabs that should stay are dropped while the preview list refreshes.