feat(coding-agent): show generated session summaries in the resume picker

[MarkAronov]

Closes #1033

Problem

The resume picker identifies sessions by a truncated first message, so you have to guess which conversation is which, or open them one at a time to find out.

Solution

Atomic now generates a one-line summary of each session once the agent goes idle, stores it in the session file, and shows it in /resume and atomic -r.

Per @flora131's guidance, this reuses the existing summarization request path — model, credentials, stream function, retry policy — with a new one-line prompt, stored separately from branch_summary, generated on idle rather than when the picker opens, and falling back to today's display when unavailable.

How it works

• Generation (core/compaction/session-summarization.ts) mirrors generateBranchSummary's pipeline minus the parts that don't apply: no entry collection, file-op tracking, preamble, custom instructions, or reasoning request. The response has whitespace collapsed and length clamped, because the picker renders one row per session and the prompt can only ask for one line.
• Orchestration (core/agent-session-summary.ts) runs fire-and-forget from agent_end. It declines when disabled, in --print/JSON mode, while streaming or compacting, without a model, on workflow-stage sessions, on very short sessions, and — the main cost control — when the last conversation message hasn't moved since the stored summary.
• Staleness is anchored to the id of the last user/assistant message the summary covers, not the leaf id. Appends move the leaf (including the summary's own append, and every model or thinking-level change), so a leaf-based check would regenerate on every idle. The picker shows the summary only while that anchor is still the newest conversation message; a later branch_summary also retires it, since the branch it described was abandoned.
• Concurrency uses a monotonic token plus a session-scoped AbortController. After the request returns, the run re-reads both the token and the anchor and discards its own result if either moved. The next prompt and session disposal both cancel it.
• Display is summary ?? name ?? firstMessage. A stale or missing summary is simply absent from SessionInfo, so the fallback needs no logic in the selector. Session id, message count, age, and cwd stay on the row.

sessionSummary.enabled (default true) turns it off.

Decisions worth a second opinion

• A generated summary currently outranks an explicitly user-set session name. That follows the fallback ordering in Improve resume list context with chat summaries #1033 ("fall back to the current session name or first message"), but it's the one call I'd happily reverse — it's a one-line change plus a test.
• Summary token usage counts toward session totals and the footer, matching branch_summary. It's deliberately excluded from cache-stats.ts, where compaction/branch_summary reset prompt-cache continuity — a separate one-shot request doesn't break the main prefix.
• Retries are silent. The retry policy is passed, but not the lifecycle callbacks, which drive a foreground "retrying summarization…" banner meant for work the user initiated.
• Known gap: navigating to an earlier point without summarizing leaves no trace in the file, so the picker can briefly show a summary describing an abandoned branch. It self-heals on the next turn; the cost of being wrong is one slightly-off line.

Tests

Added test/session-manager/session-summary-listing.test.ts (fresh; stale after a newer message; retired by a later branch summary; unaffected by tool results; absent when never generated) and test/suite/agent-session-summary.test.ts (anchored to the newest conversation message; no regeneration while the conversation hasn't moved; disabled by setting; skipped in non-interactive modes; no persistence once the conversation has outrun the request).

test/suite/agent-session-summary.test.ts                    5 passed
test/session-manager/session-summary-listing.test.ts        5 passed
test/unit/host-session-picker-local.test.ts                 
test/unit/interactive-engine-session-picker.test.ts         31 passed
test/unit/workflow-resume-selector-host-picker.test.ts      
test/session-selector-*.test.ts, internal-session-resume-*  24 passed

npm run check passes. The full npm run test:unit has two pre-existing failures on my Windows machine, both verified against clean upstream/main with none of these commits present: flaky-test-suite-runner.test.ts fails deterministically ('C:\Program' is not recognized — an unquoted path with a space when it spawns the child suite), and one load-sensitive timeout that varies by run and passes in isolation. Happy to open a separate issue for the first if it's not already known.

Follow-up

Workflow-run summaries are a second PR, as agreed on the issue — those use different storage and have no single shared transcript, so stage names and results are the right source there.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

Greptile Summary

Atomic now creates concise summaries after interactive sessions become idle, stores each summary with a conversation anchor, and uses fresh summaries in resume selection.

Verified behavior:

• A background summary response that returns after session disposal does not persist stale metadata, including when the provider ignores cancellation; the focused lifecycle suite passed 13/13 tests.
• Fresh persisted summaries replace fallback session text and are searchable in resume selection.
• Summaries retired by a branch change fall back to the session name and are excluded from summary search.

Disproved concerns:

• Stale or cancelled summary requests persisting after disposal were disproved by an executed abort-ignoring provider reproduction that observed zero stored summaries.
• Incorrect rendering or search behavior for fresh and retired summaries was disproved by terminal rendering checks and focused listing/search tests.

Confidence Score: 5/5

The PR is safe to merge; no blocking failure remains.

The final defect set is empty. Executable checks confirmed cancellation and disposal protections, freshness and retirement handling, picker display behavior, and summary search behavior.

_{Reviews (7): Last reviewed commit: "Merge remote-tracking branch 'upstream/m..." | Re-trigger Greptile}

[flora131]

Hi @MarkAronov thanks for the thoughtful work on this and for the detailed tests and documentation. We tested the exact PR head (aee30eb0ae934a6683754714fdc62c5b93c2561a) using the built Atomic CLI in a real tmux TUI session and found two lifecycle issues that need to be fixed before approval.

1. Start summary generation only after the agent has fully become idle

The summary attempt currently starts from agent_end, but that callback can run while the agent still reports isStreaming. _maybeGenerateSessionSummary() then returns early and nothing retries it.

We reproduced this with the current built --no-extensions TUI: two user/assistant turns completed, the session remained idle, and the JSONL contained four conversation messages but no session_summary entries. The resume picker therefore showed the existing fallback instead of a generated summary.

Please move the launch to a confirmed post-settlement/idle boundary, or schedule a safe deferred retry when streaming clears. Please add regressions for both the normal CLI and --no-extensions path so an eligible completed turn reliably produces a summary after idle.

Relevant location: packages/coding-agent/src/core/agent-session-events.ts:267.

2. Prevent queued summary work from running after disposal

dispose() currently aborts a summary controller only if that controller already exists. Work queued before the controller is created can resume after disposal, create a new request, contact the provider, and append to retired session state.

We reproduced this with a held-queue harness: it paused _checkCompaction(), called dispose(), and then released the queued agent_end work. The provider was called and a summary was appended after disposal.

Please track a disposed/session-generation state and reject summary work both when it starts and after each asynchronous boundary. At minimum, check ownership/disposal before auth, before contacting the provider, and before persisting the result. Please add a regression that holds the queue, disposes the session, releases the queue, and asserts zero provider calls and zero post-disposal appends.

Relevant location: packages/coding-agent/src/core/agent-session-events.ts:479-481.

These findings are based on repeatable runtime evidence rather than source review alone. In short, the first issue can silently prevent the feature from running, while the second can let it run after the session should be finished. Thank you again for the contribution and for taking a look at these cases.

[flora131]

One workflow tip: you can have Atomic run this verification for you after you make the fixes instead of driving the TUI manually.

From your PR checkout, start Atomic and give it a prompt like:

Test the changes on this PR for correctness. Build and run this branch's own
Atomic CLI in a tmux session and manually verify the feature works as the
linked issue describes, then post the evidence of the results to the PR as
a comment. Don't modify the code or the PR itself.

Atomic turns that into a tracked workflow: it scopes the acceptance criteria from the issue and PR, builds your branch, launches that exact build inside a tmux session, operates the resume picker and the rest of the TUI manually, and surfaces anything it reproduces — with the evidence (commands, pane captures, session-file contents) posted back here as a comment.

Two details in the prompt matter: "this branch's own Atomic CLI" keeps it from testing the globally installed binary, and "don't modify the code or the PR" keeps it review-only. If a specific path matters, name it in one extra sentence — for example the --no-extensions flow from the findings above.

You can watch the run with /workflow connect <run-id> while it works, and the tmux session stays alive afterward for your own inspection.

[MarkAronov]

Hi @flora131, thanks for taking the time to run this against a real build and write it up so clearly. Both findings reproduce.

The first has a sharper cause than the callback running early. I subscribed to agent_end and measured it: isStreaming is true there and stays true across the whole microtask queue, clearing only on a later macrotask. So generation worked only when await this._checkCompaction(msg) on the previous line happened to cross that boundary. It does in the unit harness, which is why seven tests passed while your run produced nothing. Good catch, this would have shipped silently.

Fixed both in one commit, since they interact: deferring to idle widens the disposal window the second finding is about.

1. await this.agent.waitForIdle() inside _maybeGenerateSessionSummary, with the supersession token claimed before the wait so a later turn abandons a parked launch.
2. A terminal _disposed flag set by dispose(), checked on entry, after the wait, before auth, before the provider call, and before persisting. abortSessionSummary() bumps the token too, since a parked launch has no AbortController yet. dispose() is idempotent.

Regressions: a launch fired from inside agent_end while isStreaming is true, which also asserts that condition is reproduced so it cannot pass for the wrong reason; and dispose then release, asserting zero provider calls and zero appends. Both fail against the pre-fix source, with two more covering the new token semantics.

One scope question before I go further. --no-extensions only affects the resource loader, not _extensionMode, and the harness already runs with no extensions, so that path is covered. For the normal CLI I have stayed at harness level. Would you like a real CLI regression that spawns the binary and checks the JSONL? Happy to add it, just want to match the bar you have in mind.