fix(cli): discover resumable sessions from /resume - #3582
Conversation
Generated-by: Codex
Astro-Han
left a comment
There was a problem hiding this comment.
Reviewed at exact head e23405ce34db55480faf0f2a269cc2105935c8a2.
Coverage: how /resume discovers sessions, and the call chain from picking one to actually resuming. Not covered: wording.
Thanks for adding this entry point — the gap it targets is real. Two things need fixing before it does what it says, and both are reproducible on the ordinary user path.
[P2] onlyResumable filters on "attachable", not "has a safe boundary to resume"
packages/cli/src/pi-tui-runner.ts:2214-2215 selects entries with availability.get(session.id)?.available === true. But that availability comes from inspectSessionResumeAvailability at packages/cli/src/session-driver.ts:182-190, which only checks that session.cwd exists and is realpath-able. The Runtime Host implementation is the same shape, and for remote sessions it returns true for anything that has a cwd at all.
The authority for "is there something to resume" is elsewhere: the Host's turn.resume.query, where the Runtime plans a continuation only from that session's failed/cancelled inline run and otherwise reports resume_candidate_missing. The list path never calls it, and does not consult runningTurnIds or corrupted/unexecutable state either.
So an ordinary completed session, a session that is currently running, or one with no continuable run all appear in /resume as long as their working directory still exists. On remote, runtime-host-tui-command.ts:97-102 pins the scope to all while the new path applies no project predicate, so sessions from other projects are listed too. The same weak predicate also drives the startup hint at pi-tui-runner.ts:2282-2297, which will tell the user a plain attachable session "has an interrupted run".
Suggested direction: have a Runtime-owned resumability query return each session's real disposition, and filter here on current project, deleted workspace, running, and corrupted state — rather than reusing SessionResumeAvailability, which only answers cwd attachability.
[P2] Selecting from the picker does not actually resume
With no attached session, pi-tui-runner.ts:2134-2137 opens showSessionList({ onlyResumable: true }) and returns. The picker's onSelect at :2251-2260 calls goToSession(item.value), which on the idle path runs switchSession (:1649-1652) — and the comment right above goToSession says it plainly: /session is view navigation.
switchSession in runtime-host-session-driver.ts:471-524 validates cwd and the execution boundary, opens a subscription, and attaches a still-running root turn. It never calls turn.resume.query or turn.resume.start. The only driver path that starts a safe-boundary continuation is resumeLatest() at :325-349.
The user therefore picks a session, the picker closes as if the action succeeded, and the interrupted turn does not continue — they typically have to type /resume a second time so the current-session path reaches resumeLatest. That is the core function of the new entry point.
The new test at pi-tui-runner.test.ts:3265-3292 only asserts list text and filtering; it does not press Enter and assert that resumeLatest or a turn start follows, which is why this got through.
Suggested direction: make the selection path call a Runtime-owned switch-and-resume operation, or call resumeLatest once explicitly after a successful switchSession, keeping race/parked/failure outcomes visible.
Note on CI
check-runs on this head is total_count 0 — no run at all, which is neither green nor red. Even once the two items above are fixed, the gate needs terminal green on the new head.
Verification and limits
Changed-file Biome and git diff --check pass. A full CLI build could not be completed in our environment — pre-existing workspace drift unrelated to this PR blocked it — so no targeted-suite pass is claimed here; the findings above are established by reading the call chains at this exact head.
Generated-by: Codex
|
Follow-up fix pushed in the new head.
Verification on the new head: CLI build, typecheck, lint, format check, |
Summary
Fixes #3508.
When the TUI has no attached session,
/resumenow opens a picker limited to sessions whose resume availability is ready, instead of attempting an attached-session-only resume. Startup also performs a best-effort availability check and surfaces a passive hint for the current or cwd session when safe-boundary resume is available.Implementation
/resumewithout an attached session./sessionrows, attached-session resume behavior, sandbox boundaries, and Desktop policy unchanged.Verification
node --test --test-name-pattern="opens a picker containing only resumable" packages/cli/dist/__tests__/pi-tui-runner.test.js— passed.npm --workspace maka-agent run build— passed.npm --workspace maka-agent run typecheck— passed.npm run lint -- packages/cli/src/pi-tui-runner.ts packages/cli/src/__tests__/pi-tui-runner.test.ts— passed.npm run format:check -- packages/cli/src/pi-tui-runner.ts packages/cli/src/__tests__/pi-tui-runner.test.ts— passed.git diff --check— passed.npm --workspace maka-agent test— 378 passed, 12 failed, 1 skipped; failures are existing environment/Windows-dependent tests outside this diff.Not run: full repository build and Docker-based checks; this is a pure CLI/TUI unit behavior change with no external service dependency.
AI use
Tool(s) and scope: Codex assisted with remote issue selection, implementation, regression testing, and PR text. The commit includes a
Generated-by: Codextrailer.Checklist
Does this PR entail a change in behavior?
/resumenow discovers resumable sessions when no session is attached.