Session recap and recall
Your coding agent can use recorded sessions to pick up where you left off or find earlier work on a problem. A recap catches you up on a session; recall finds the sessions that matter to your question.
After setting up the CLI, ask your agent in ordinary language. You can describe the work even when you do not know the session’s name or ID.
Catch up and continue
Section titled “Catch up and continue”Start a new conversation with the context you want to recover:
Catch me up on the last few sessions in this repo. What did we finish, and what is still open?
Read session acme-billing-rate-limit and tell me what remains before we can ship it.
Summarize the work across this session’s continuations, including the decisions and unfinished tasks.
The agent can read the recorded plan, summary, and conversation to recover the work’s intent and progress. Ask it to explain the next step before continuing, especially when another person or agent did the earlier work.
Resume an unfinished plan
Section titled “Resume an unfinished plan”A session that ends mid-plan leaves its declared task list behind. Your agent can find it without knowing which session wrote it:
Is there an unfinished plan in this repository? Show me where it stopped and continue from the next task.
list_repo_plans lists a repository’s declared plans, open ones by default, with each plan’s progress, next task, and attached sessions. get_declared_plans reads one plan’s documents and full task list, or every plan a session touched. Both are in the kcap-sessions MCP server. Progress the resuming session records goes on the same plan, and the plan shows on that session’s Overview too.
A plan is done when its progress reports finished. is_complete means something else: that nothing in the plan is hidden from you. A plan with contributions from sessions you cannot see is never reported as finished. An active session attached to a plan is not proof that anyone is still working on it; the agent checks when the plan was last touched.
Find a past decision
Section titled “Find a past decision”Describe the problem, decision, or change you remember:
Have we worked on this timeout before? Find the relevant sessions and explain what we tried.
Why did we choose a queue here? Find the conversation where we made that decision.
Add a repository or author when you know one. Ask for links to the source sessions so you can inspect the original context in Sessions.
Distinctive words work best: an issue key, an error message, a function or file name. Search ranks sessions by how many of the search terms they contain, with identifiers counting double, and a session matching every term ranks first. Each result says whether it matched the words literally or only by meaning. When nothing matched literally, the result says so; treat the remaining hits as possibly related, not as the session you asked for.
For guidance you want future sessions to reuse, ask the agent to save the conclusion as shared memory.
Check related work
Section titled “Check related work”Your agent can also look at visible active and ended sessions in a repository:
Who else is working in this repository, and what are they working on?
Use this to understand parallel work before deciding what to change. The results provide context for coordination; they do not reserve files or guarantee that nobody else is editing them.
Choose the scope
Section titled “Choose the scope”Recall starts with the repository you launched the agent from. When a search finds little there, it can widen to other repositories you can access. State the boundary in your request when it matters:
Look only in acme/billing for the retry-policy decision.
Search across our repositories for earlier work on rate limiting.
The agent can only read sessions and details your account is allowed to see. Knowing a session ID does not grant access. See Visibility & sharing.
When a summary is missing
Section titled “When a summary is missing”A live session or a session without a generated outcome may still have a recorded conversation the agent can read. Asking for a recap does not itself generate a new stored outcome.
For an ended session, use Generate outcome in the browser when available. Session outcomes explains generation and its prerequisites.
Read directly from the terminal
Section titled “Read directly from the terminal”You can also read a recap yourself:
kcap recap <sessionId> # available plan, summary, and turn outlinekcap recap --repo # recent summaries in this repositorykcap recap --chain <sessionId> # include linked continuationskcap recap --full <sessionId> # read the recorded transcriptUse a session ID or meta-session slug. The CLI command reference covers reading individual turns and other session lookup options.
