[Bug]: Human-readable terminal output omits orphaned state; recovery needs current retest
- Dominant language
- TypeScript
- Stars
- 71.3k
- Forks
- 4.7k
- Avg merge
- 17h 8m
- Merged PRs (30d)
- 475
Description
## Current scope — 2026-09-04
The actionable read-surface gap is that JSON exposes `orphaned` while human-readable terminal output does not. The broader claim that a live orphan can never be reattached needs retesting after the persistence/recovery work discussed in #15227, including #15644. A bulk-close command is an additional feature request, not proof that individual recovery is absent.
`orphaned` describes a missing pane binding; it does not mean the agent has exited or that cleanup is safe. Keep process evidence (`live` / `unverifiable` / `exited`) separate, and do not hide or bulk-close live work merely because it has no renderer pane.
## Historical observation
On Windows / Orca 1.4.184, 17 of 30 listed terminals were orphaned across 11 worktrees. JSON showed `orphaned: true`, but the human output printed the same `connected` status for terminals with and without a pane. A live orphan could still be read and written by handle; CLI inspection remained available even though the UI pane was absent.
The human output excerpt was:
```text
term_16307b96-… Orca Worker connected F:/…/gate-porte-4158
term_61baf167-… (untitled) connected F:/…/recording-minimal
```
The first had a pane; the second did not. The missing distinction led me to look for the wrong cause.
## Acceptance
Expose the already-known orphan/pane-binding state in human-readable list/show output and keep it separate from process liveness. Compare JSON and human output for the same handles, with an attached control terminal. A filter may be useful, but adding bulk termination or a new recovery subsystem is not required to close this read-surface issue.
Retest adoption into a pane before claiming that it is impossible on a current build. The previous count and recovery experience are historical; no new orphan, reattach or close operation was performed for this edit. Related: #15227 (the persistence scenario), #15232 (visibility classification), #15944 (Dispatch-aware reclaim).
Contributor guide
Assessment
This issue has not been assessed yet.