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]

Reviewed at 253fb50e595de0604c0c22b303fae1fa8023af82. Both of the [P1]s we raised earlier are fixed by this commit. No P0-P2 remain. Two gate blockers below, one of which is not yours to fix in code.

Correcting our own scope first

An earlier round of this review was working from a 252-file, +7405/-6516 diff. That is not what this PR changes. This branch was rebased onto main and replayed roughly twenty squash-merged commits; because squashing produces new SHAs, git cannot see them as shared history, so the merge-base is stuck at an old commit and every merge-base-relative view — the Files tab and the REST file list included — inflates accordingly. Those views are not wrong; they accurately report merge-base-to-head, which is simply not the same question as "what did the author change here".

The author-owned delta is one commit:

253fb50e fix(cli): separate session attach and resume discovery
  packages/cli/src/__tests__/pi-tui-runner.test.ts  +30
  packages/cli/src/pi-tui-runner.ts                 +37/-14
  packages/cli/src/runtime-host-session-driver.ts   +17/-17
  packages/cli/src/session-driver.ts                 +1
  4 files, +68 / -17

We are stating this because we got it wrong in this thread before stating it, and because the wrong number changed a conclusion further down.

Both prior [P1]s are closed

Attach availability no longer answers the resume-candidate question. getSessionResumeAvailability drops its host branch and returns inspectRuntimeHostSessionResumeAvailability unconditionally; the narrow turn.resume.query path moves into a new getSessionResumeCandidateAvailability. showSessionList picks by mode, and — this is the line that fixes the reported symptom — the selection handler changed from if (availability.get(item.value)?.available === false) return; to if (options.onlyResumable && availability.get(item.value)?.available === false) return;. /session no longer refuses to navigate to a session because a resume-candidate check said false. The commit subject says exactly this, and the code matches it.

The startup enumeration race is fixed at the mechanism, not by moving the timer. A memoised sessionListPromise now backs a shared listSessions(), so showSessionList and announceResumeAvailability join one in-flight enumeration instead of issuing two. announceResumeAvailability also returns early when the driver lacks getSessionResumeCandidateAvailability. The setTimeout(..., 0) is still there, and that is fine: the timer was never the defect — the concurrent duplicate enumeration was, and it is now memoised away.

One supporting argument from our earlier review should be retired rather than repeated: we noted that the availability map was built with a bare Promise.all(sessions.map(...)) while the sibling foreign-session branch had per-item containment. That asymmetry is gone — and specifically, this commit is what added the per-session try/catch. It is not that our evidence went stale; the author fixed it.

Gate: two blockers, both needing one push

1. Formatting. The test job fails at Check formatting on pi-tui-runner.ts around the new resume-availability expression. That step runs before the tests, which has a consequence worth naming: no test on this head has executed, so CI currently cannot tell you anything about the change itself. npm run format resolves it.

2. TS2304: Cannot find name 'decodeStoredMessage' in the package job — please do not hand-edit this. The symbol is in packages/storage/src/__tests__/codex-session-adapter.test.ts:267, which your commit does not touch. The branch replayed the older versions of #3562 and #3520 in the order that briefly broke main: the rename landed first, then an assertion still using the old symbol. main was repaired afterwards by #3656, but this branch replayed before that fix existed. Rebasing onto current main brings #3656 with it and clears this. Editing line 267 by hand would mean changing a file that is not part of your change.

The PR is also CONFLICTING, so a rebase is required regardless — one push can settle all three.

One thing to check on your side

The two review threads above show replies from you reading System.Collections.Hashtable[...]. That is a PowerShell object stringified by whatever tooling posted them, so no text of yours actually arrived. From the GitHub UI the threads look answered, which is why we are pointing it out rather than assuming you chose not to reply. If you meant to say something there, it will need reposting.

[Astro-Han]

Correction to my previous review on this PR (5004256305), specifically to the scope paragraph.

I wrote that the author-owned delta is one commit, 4 files, +68/-17. That is wrong. It is three commits and 5 files.

9e24a005 fix(cli): discover resumable sessions from /resume            2 files, +63/-2
f2c24a35 fix(cli): resume the selected interrupted session             4 files, +25/-6
253fb50e fix(cli): separate session attach and resume discovery        4 files, +68/-17

Union: pi-tui-runner.ts, runtime-host-session-driver.ts, session-driver.ts, __tests__/pi-tui-runner.test.ts, __tests__/runtime-host-session-driver.test.ts. The +68/-17 I quoted is the tip commit alone, not this branch's contribution.

How I got it wrong is worth stating, because the previous review's whole first section was about scope. I listed the commits between the merge-base and the head, truncated the output, and read the top entry as the PR's own work. The other two author commits are further down that list, interleaved among the twenty-odd replayed main commits. A truncated observation reported as a fact — the same failure mode I was describing one paragraph earlier.

The reliable way to separate them is patch equivalence rather than reading a commit list:

git log --cherry-pick --right-only --no-merges origin/main...<head>

which returns exactly these three and marks the other nineteen as already present on main. Credit to a reviewer on our side for pointing out that subject-line matching is not sufficient here; this is what caught my error.

Nothing else in that review changes. Both [P1]s are still closed, and I verified that by reading the tip commit's actual diff — the removal of the host branch from getSessionResumeAvailability, the new getSessionResumeCandidateAvailability, the options.onlyResumable && guard on the selection handler, and the memoised sessionListPromise. The two gate blockers are unchanged: run npm run format, and rebase onto current main so that #3656 clears the TS2304 on a file that is not part of your change.

The practical difference for you is only in how much of this branch a reviewer should be reading: five files across three commits, not four files in one.

[Astro-Han]

Correcting one sentence in 5004276704 — a tooling claim, not a conclusion about this PR.

I wrote that

git log --cherry-pick --right-only --no-merges origin/main...<head>

"returns exactly these three and marks the other nineteen as already present on main". It does not mark anything. --cherry-pick omits commits whose patch is already present on the other side; nothing in its output refers to them. The marking form is git cherry -v (+ / -) or --cherry-mark, which prints = for a patch-equivalent commit and > for one only on the right side. On this branch --cherry-mark gives 19 = and 3 >.

Two limits on that command that my wording also glossed over:

It produces a candidate classification, not a proof of ownership. A replayed commit rewritten during conflict resolution is no longer patch-equivalent and will appear as author work; conversely, a commit the author genuinely wrote that happens to be patch-identical to something already on main is omitted and silently disappears from their delta. The first direction costs extra reading, the second can hide real author work, and neither is detectable from the command's output alone.

--no-merges is --max-parents=1, so any delta introduced by a merge commit's own conflict resolution is excluded. That is harmless here — this branch has no merge commits, it was rebased — but the exclusion is silent, so it is worth stating rather than assuming.

None of this changes the facts in the previous correction, which an independent reviewer on our side re-derived from a fresh fetch: three author commits (9e24a005, f2c24a35, 253fb50e), five files in the union, none of them the Codex adapter test, and all three on this head's first-parent chain. The [P1] closures and the two gate items are likewise unaffected — still npm run format, and rebase onto current main so #3656 clears the TS2304.

[Astro-Han]

CI note, with one part that needs your judgement rather than a mechanical fix.

This head's checks had never executed — the run was parked awaiting maintainer approval. I released it (32686697153), so what follows is a real result and not a new regression from anything on our side.

Unlike the other parked runs I released today, this one gets all the way through. Lint, formatting, the Astryx inventory, Build, Typecheck, both Knip gates and the Linux sandbox smoke all pass. It fails at step 28, Run affected standard workspace tests, with exactly two failures, both in packages/cli/dist/__tests__/pi-tui-runner.test.js. They are different in kind, so I am separating them.

---

1. /session keeps attachable rows when resume discovery fails for another session — a new test this PR adds, failing on a string the layout truncates. Certain, and cheap to fix.

pi-tui-runner.test.ts:3373 asserts /attachable/, but the rendered row is:

→ Existing chat       attachab claude-subscription claude-sonnet-4-5
  Existing chat       archived session archived

The id column is eight characters wide, so fakeSessionSummary('attachable', …) renders as attachab. The sibling row passes only because archived happens to be exactly eight characters. Nothing is wrong with the feature — the assertion is on a full-length id the column cannot show. A shorter id, a wider FakeTerminal, or asserting on the visible form all resolve it.

2. keeps live status visible for a session without a cwd but prevents resuming it — a pre-existing test, and this is a regression. Certain that it regressed; I have not pinned the mechanism.

What I established:

• This test exists on the merge base, 84ed9a31018ce31aee228473af4d03c35def0f3f, which is a main commit whose own test check is success. So it passed there.
• On this head it fails. Same test, same name, not touched by your diff.

The expected/actual gap is not a near-miss. It expects the session list to render a row reading roughly Legacy chat … · running Missing working directory; what the terminal actually contains is:

 Note: Resumed session "Legacy chat"

and then an otherwise empty screen — no list at all, and a resume that did happen. The test's whole point is that this session must stay visible but must not be resumable.

I am not going to guess which of your changes causes it, because two new paths could and I would rather you check than have me assert. For what it is worth, both are in pi-tui-runner.ts:

• resumeSession now falls through to showSessionList({ onlyResumable: true }) when getSessionId() returns nothing, where it previously did not; and inside that list, selecting a row calls runControl(resumeSession) directly.
• the availability lookup gained a preferred source under onlyResumable: getSessionResumeCandidateAvailability is consulted ahead of getSessionResumeAvailability and the inspect… fallback.

To be fair to the second one: getSessionResumeCandidateAvailability does check cwd first (runtime-host-session-driver.ts, if (!session.cwd) return { available: false, reason: 'Missing working directory' }), so the obvious "the new authority is weaker" story does not hold as stated — which is exactly why I am not stating it. The test's driver is a stub, so which of the three sources it actually reaches is worth checking directly.

---

Neither failure is flaky. The first is deterministic by construction, and the second contradicts a green run on its own merge base. Both are reproducible with npm --workspace @maka/cli run build followed by the two test names, which will be faster for you than another CI round trip.

中文

CI 提示，其中一条需要你判断，不是机械修复。

这个 head 的检查此前从没执行过——run 卡在等 maintainer 放行，我已放行（32686697153），所以下面是真实结果，不是我们这边引入的新回归。

与我今天放行的其他几个不同，这个 run 一路走到了很后面：lint、格式、Astryx 清单、Build、Typecheck、两个 Knip 门、Linux sandbox smoke 全过。它失败在第 28 步 Run affected standard workspace tests，恰好两个失败，都在 pi-tui-runner.test.js。两者性质不同，我分开写。

1. /session keeps attachable rows when resume discovery fails for another session —— 本 PR 新增的测试，断言在一个被布局截断的字符串上。确定，且好修。

pi-tui-runner.test.ts:3373 断言 /attachable/，而实际渲染出的行是 → Existing chat attachab claude-subscription …。id 列只有 8 个字符宽，所以 fakeSessionSummary('attachable', …) 渲染成 attachab；旁边那行能过只是因为 archived 恰好是 8 个字符。功能没问题，是断言写在了列显示不出来的完整 id 上。 换个短 id、把 FakeTerminal 加宽、或者断言可见形式，都能解决。

2. keeps live status visible for a session without a cwd but prevents resuming it —— 既有测试，这是一处回归。我确定它回归了，但没有钉死机制。

已确立的事实：这个测试在 merge base 84ed9a310（一个 main 提交）上存在，而该提交自己的 test 检查是 success，所以它在那里是通过的；在本 head 上它失败，同名同测试，且不在你的 diff 里。

期望与实际的差距不是"差一点"：它期望会话列表渲染出一行大致为 Legacy chat … · running Missing working directory，而终端实际内容是 Note: Resumed session "Legacy chat" 之后一片空白——没有列表，而且确实发生了一次 resume。 这个测试的全部意义就是"该会话必须可见但不可 resume"。

我不去猜是哪一处改动导致的，因为有两条新路径都可能，我宁愿你去查，也不愿我来断言。两条都在 pi-tui-runner.ts：① resumeSession 现在在 getSessionId() 为空时会落到 showSessionList({ onlyResumable: true })（此前不会），而该列表里选中一行会直接 runControl(resumeSession)；② availability 查询在 onlyResumable 下新增了优先来源，getSessionResumeCandidateAvailability 排在 getSessionResumeAvailability 和 inspect… 兜底之前。

为第二条说句公道话：getSessionResumeCandidateAvailability 确实先查了 cwd（runtime-host-session-driver.ts 里 if (!session.cwd) return { available: false, reason: 'Missing working directory' }），所以"新权威更弱"这个顺理成章的说法并不成立——这正是我不去这么说的原因。该测试用的是 stub driver，它实际走到三个来源中的哪一个，值得直接查一下。

两个失败都不是 flake：第一个由构造决定必然失败，第二个与它自己 merge base 上的绿色 run 相矛盾。都可以用 npm --workspace @maka/cli run build 加上那两个测试名在本地复现，比再等一轮 CI 快。