Repository navigation
CLI terminal close can never close a background tab that failed reveal — headless close path throws tab_not_found for tabs that were never persisted #10747
Description
Summary
A terminal created via CLI that fails reveal at creation time (Terminal reveal timed out ... could not make it discoverable, reported as [background]) becomes permanently unclosable through the CLI:
orca terminal listshows the tab normally (tab id, terminal handle, agent status).orca terminal close --terminal <handle>(with or without--tab) consistently fails with{"ok":false,"error":{"code":"runtime_error","message":"tab_not_found"}}.- Even after the process inside the PTY exits on its own, the tab entry stays in
terminal listindefinitely (until the runtime restarts).
The root cause is an asymmetry: list reads runtime hot state (where the tab exists), while the headless close path requires a persisted workspace-session record (which was never written because reveal/adopt failed). A tab that never made it into the persisted session can therefore never satisfy the close path's de-persist step.
Observed on a relay-connected SSH worktree (relay 0.1.0+0eee5f4c09ed); 6 out of 6 worker terminals created in one session with the [background] warning all reproduced it. Not a transient wedge — retries after the runtime was healthy again failed identically.
Reproduction
orca terminal create --worktree active --command "sh <script>"in a setup where reveal times out (e.g. SSH worktree with the desktop app not foregrounded). Creation output showsTerminal reveal timed out ... could not make it discoverableand the terminal is reported as[background].orca terminal close --terminal <handle> --tab(or without--tab).- Observe
tab_not_found. The tab remains interminal list. - Optionally let the process inside the PTY exit — the tab entry still remains listed.
Root cause
CLI terminal close → RPC terminal.close / terminal.closeTab (src/cli/handlers/terminal.ts:153-158). Because the renderer never adopted the tab (consistent with the reveal timeout), the close flow classifies it as a runtime-owned headless tab and takes the headless branch:
src/main/runtime/orca-runtime.ts:5767-5774—closingWholeParent && !this.tabs.has(tab.parentTabId)→closeHeadlessMobileTerminalTab(...).src/main/runtime/orca-runtime.ts:5943-5950—closeHeadlessMobileTerminalTabcallsremovePersistedHeadlessTerminalTab(worktreeId, parentTabId).src/main/runtime/orca-runtime.ts:5206-5220—removePersistedHeadlessTerminalTabrunscloseTerminalTabInWorkspaceSession(session, worktreeId, parentTabId)against the persisted session (src/shared/workspace-session-terminal-tab-close.ts). The tab was never persisted, soresult.closedisfalse→throw new Error('tab_not_found').
So the failure is not "tab does not exist" — the tab exists in hot state and is listed — but "tab has no persisted record to remove". Two secondary effects compound it:
- PTY exit terminates the PTY but does not reap the hot-state tab entry, so dead
[background]tabs accumulate interminal listuntil the next runtime restart rebuilds hot state from the persisted session. - There is no CLI-reachable fallback: every close variant funnels into the same de-persist step.
Suggested direction
When the headless close path finds no persisted record for a tab that does exist in runtime hot state, it should degrade instead of throwing: kill the PTYs it knows about, drop the hot-state tab entry, and report success — the invariant "persisted record exists" simply does not hold for never-adopted background tabs. Alternatively (or additionally), reap hot-state tab entries when their last PTY exits, and/or persist the tab even when reveal times out so the normal close transaction applies.
Happy to provide the full CLI transcripts from the 6-terminal reproduction if useful.
Activity
AmethystLiang commentedon Jul 26, 2026
thanks for reporting this. will look into it!
nwparker commentedon Jul 27, 2026
Repro status: has_repro (code-path, conclusive)
Summary
CLI
terminal closecannot close a background tab that failed reveal: list shows the tab (hot state), close throwstab_not_foundbecause the headless close path requires a persisted workspace-session record that was never written.Code evidence
closeHeadlessMobileTerminalTab→removePersistedHeadlessTerminalTab(src/main/runtime/orca-runtime.ts~5490, ~6246).removePersistedHeadlessTerminalTabde-persists via workspace session; if no record, throwstab_not_found(~5500).Repro steps
[background]/ "Terminal reveal timed out … could not make it discoverable".orca terminal list— tab present.orca terminal close --terminal <handle>→tab_not_found.Expected
If tab exists in hot state but has no persisted record, kill PTYs, drop hot entry, succeed (or persist even when reveal fails).
danielxxomg commentedon Aug 4, 2026
Additional reproduction on a remote folder workspace (client 1.4.163, headless runtime 1.4.164, Linux client).
I hit the same hot-state/persisted-state mismatch while cleaning up a remote folder workspace.
Environment
orca-ide)terminal list --jsonreported three connected/writable terminals: one floating root terminal and two terminals in one folder-backed headless group.Observed cleanup
terminal close --tabsucceeded for the floating root terminal, but reportedptyKilled: false.connected: trueandwritable: true.--tabreturnedtab_not_found; the pane-close variant returnedterminal_handle_stale.terminal showstill returned the terminal, andterminal listcontinued to report it after the failed close attempts.terminal stop --worktree ...returnedselector_not_found;worktree psandproject setupswere empty for the remote runtime, even thoughterminal listexposed a folder workspace ID.Expected behavior
A terminal returned by
terminal listshould be closable using its current identity. Once the last terminal in a folder workspace is closed, the folder workspace should disappear from the client, or the CLI should expose a stable folder selector for cleanup.Actual behavior
The list/show paths and close paths disagree for the remote folder terminals. The terminals remain visible and connected after the close failure, and there is no CLI cleanup path through the worktree selector. No filesystem deletion was attempted.
Minimal reproduction
terminal list --environment <saved-environment> --json.terminal close --environment <saved-environment> --terminal <listed-handle> --taband retry without--tab.tab_not_found/terminal_handle_stale, then re-runterminal listandterminal show.This appears related to #10747's hot-state versus persisted-session mismatch and #11875's terminal-handle/close-path disagreement. The additional aspect here is that the affected terminals belong to a folder-backed remote headless workspace that does not resolve as a worktree selector.
fix: close headless terminal tabs whose persisted session record is m…