stablyai / stablyai/orca

[Bug]: Human-readable terminal output omits orphaned state; recovery needs current retest

Open
#15,313 2 comments 0 reactions 1 assignee Claimed by @Jinwoo-H View on GitHub
os:Windows
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.