fix(cli): discover resumable sessions from /resume

[mikemikimike]

Summary

Fixes #3508.

When the TUI has no attached session, /resume now 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

• Reused the existing session resume-availability checks.
• Added an availability-filtered picker mode used only by /resume without an attached session.
• Kept existing /session rows, 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

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Codex assisted with remote issue selection, implementation, regression testing, and PR text. The commit includes a Generated-by: Codex trailer.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suite pass locally

Does this PR entail a change in behavior?

• Yes — /resume now discovers resumable sessions when no session is attached.
• No

[Astro-Han]

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.

[mikemikimike]

Follow-up fix pushed in the new head.

• /resume selection now switches to the chosen session and immediately runs the safe-boundary resume flow; it no longer stops after view navigation.
• Runtime Host resume availability now delegates to turn.resume.query, so completed/running/no-candidate sessions are not treated as resumable merely because their cwd is attachable.
• Added coverage that selects the picker row and observes resumeLatest().

Verification on the new head: CLI build, typecheck, lint, format check, git diff --check, the picker/resume regression, and the Runtime Host availability test pass.

[Astro-Han]

Reviewed at exact head f2c24a35. Two [P1]s, both inline. Publishing on behalf of a reviewer without write access here; the analysis is theirs, and I re-verified both against this head before posting.

Gate status is red, but not because of this PR. The test job's Build step fails on apps/desktop/src/main/__tests__/goal-services-adapter.test.ts:64,70,76 with TS2353: 'type' does not exist in type 'SessionChangedEvent'. That file is untouched here — this PR changes four packages/cli files. The root cause was already fixed on main by cded195 (#3642), so merging current main into this branch and re-running should clear it.

The direction is right: /resume should be able to open a picker when there is no current session, and startup should tell you an interrupted run exists. The two findings are both about the resume predicate being reused where an attachability predicate is what the caller needs.

[Astro-Han]

[P1] /session now refuses to navigate to sessions that are perfectly attachable.

On the host path this used to return { available: true } unconditionally (see the inspectRuntimeHostSessionResumeAvailability change further down, where the old location.kind === 'host' ? Promise.resolve({ available: true }) branch is preserved but no longer reached from here). It now returns the result of turn.resume.query, which answers a narrower question: does this session have an interrupted run with a safe boundary to resume from?

But showSessionList has only one availability map, and both /session and /resume read it. In pi-tui-runner.ts the selection handler does if (availability.get(item.value)?.available === false) return; — so under /session, a completed session, a session with no resume candidate, and a currently-running session are all now unselectable. Before this change every one of them could be attached.

That these are two different predicates is already visible in the code: switchSession validates only cwd attachability, not resume readiness. Please split them — keep getSessionResumeAvailability for /resume and give /session its own attachability query — rather than overloading one field.

Second reachable path, same root cause: for an archived session turn.resume.query rejects with session_archived. The availability map is built with a bare Promise.all(sessions.map(...)) (pi-tui-runner.ts:2170-2179) with no per-session error containment, so one archived row takes down the whole picker — /session simply never opens. Worth noting that the sibling foreign-session scan in that same Promise.all is guarded, with .then(summaries => ..., error => ({ error })) and an explicit comment about surfacing rather than swallowing the error. The Maka-session branch deserves the same treatment: per-session failures should degrade that row, not the list.

[mikemikimike]

System.Collections.Hashtable[3839511828]

[Astro-Han]

[P1] Startup fires a second, unconditional listSessions() that races the user's own.

announceResumeAvailability is scheduled with setTimeout(..., 0) at the end of the boot path and calls input.driver.listSessions() for every launch, whether or not there is anything to announce. If the user opens /session immediately, that call is in flight concurrently with showSessionList's own listSessions().

This is not just theoretical: the existing CLI test blocks prompts while the session list is loading fails reproducibly at this head (full pi-tui suite: 131 pass / 1 fail), because DeferredListSessionsDriver has a single shared resolver and the two enumerations contend for it. A test that was green before this PR and is red after it is the finding, independent of whether the shared-resolver fake is an ideal model of the real driver.

Two things to fix: avoid the duplicate enumeration (reuse the session list the boot path already has, or gate the announcement on cheaper state), and add a regression test that pins the concurrent-open behavior so this does not silently come back.

The catch {} with its "advisory and must never prevent the TUI from starting" comment is the right instinct for this feature — the problem is the I/O it performs on the way there, not its failure handling.

[mikemikimike]

System.Collections.Hashtable[3839511832]