` only after the two-refresh confirmation flow; a changed tree or live lease refuses the non-force delete.
- Codex delete uses the local `codex app-server` archive flow plus cleanup of archived rollout files and local index/state entries.
- Claude Code delete intentionally refuses live sessions, then removes matching `projects/`, `file-history/`, `session-env/`, `tasks/`, and stale `sessions/*.json` artifacts from local `.claude/` storage. This follows the official `.claude` storage guidance: Claude Code does not expose a delete subcommand, but its local session data can be removed directly.
- Non-interactive mode (missing TTY stdin/stdout) prints a tab-separated snapshot and exits.
## Local Development
```bash
pnpm install
pnpm dev
```
Useful scripts:
```bash
pnpm start
pnpm dev
pnpm build
pnpm typecheck
pnpm lint
pnpm check
pnpm test
```
## Mission Control Paired Release
Mission Control session stop and Ground Control's Mission Control `K` path are a synchronized release pair. Ground Control uses `mc` first and falls back to the `mctrl` alias only when `mc` is unavailable. It does not inspect command versions, help text, or capabilities to select a behavior.
The current Linux implementation verification is local: the isolated cross-repository runner passed the five documented scenarios. The immutable-SHA Linux, macOS, and Windows workflow is a separate post-authorization release gate. No hosted run is claimed here; until explicit authorization produces hosted receipts, that gate is pending. See [`docs/mc-child-abort-release.md`](docs/mc-child-abort-release.md) for the operator and release contract.
## Project Structure
```text
bin/ CLI wrapper
src/db/ OpenCode + Codex + Claude Code + Pi/omp/GJC + Mission Control data adapters
src/ui/ TUI components
src/config/ color and agent configuration
src/lib/ status detection logic
dist/ compiled output
```
## Session Status Detection
OpenCode status is derived from the latest message in the OpenCode SQLite database. The detection pipeline reads the most recent `message` row per session, parses its JSON `data` column, and applies status detectors in priority order. Codex status is mapped conservatively from thread/task events plus `thread_spawn_edges`, Claude Code status is mapped from local session registries plus JSONL conversation logs and subagent transcripts, and Pi/omp/Gajae Code status is mapped conservatively from JSONL message/model/thinking events. Richer raw detail is surfaced separately in the UI.
### Status Priority
| Priority | Status | Condition |
|---|---|---|
| 1 | `failed` | `finish === "error"` |
| 2 | `waiting` | Question tool is running AND no user response yet (see Waiting Detection below) |
| 3 | `completed` | `finish === "stop"` OR `time.completed` is a finite number |
| 4 | `running` | Not failed, not waiting, not completed |
| 5 | `unknown` | Message data is null, empty, or failed JSON parsing |
### Finish Values
The `finish` field on the latest message indicates how the session step ended:
| `finish` | `time.completed` | Detected Status | Display Label |
|---|---|---|---|
| `stop` | — | `completed` | Completed |
| `tool-calls` | absent | `running` | Running |
| `error` | — | `failed` | Failed |
| `other` | present | `completed` | Completed (other) |
| `length` | present | `completed` | Completed (length) |
| `unknown` | present | `completed` | Completed (unknown) |
| _undefined_ | absent | `running` | Running |
| _no message_ | — | `unknown` | Unknown |
When `finish` is `"other"`, `"length"`, or `"unknown"`, the status label appends the reason in parentheses — e.g. `Completed (other)`, `Completed (length)`.
### Waiting Detection
A session is `waiting` when the question tool is active and awaiting user input. This uses a secondary signal from the `part` table:
1. Find the latest `part` row with `type === "tool"` and `tool === "question"` where `state.status === "running"`
2. Compare its timestamp against the latest user message time
3. If the question tool time is newer → `waiting` (overrides `running`)
Waiting never overrides `failed` or `completed`.
### Display Override: AWAITING SUBAGENT
A `completed` root session that has running child sessions displays as **AWAITING SUBAGENT** instead of Completed. This reflects that the parent is technically done but work continues in subagents. The effective status becomes `running` for filtering and sorting purposes.
### Hierarchy Filter: Latest Mode
In the hierarchy view's "latest" filter mode, subagent sessions are filtered as follows:
- **Active** subagents (pending/running/waiting) are always shown
- **AWAITING SUBAGENT** subagents (completed with active children) are always shown
- **Terminal** subagents (completed/failed/unknown with no active children) — only the most recently updated one is shown
## License
MIT
---
Supervised by NoizBuster, Written by OpenCode
