Problem
A realistic engineering task is not a single uninterrupted run. The agent investigates, reaches a decision it should not make alone, asks a question, and waits. The answer may come back in minutes, or the next working day. Meanwhile a build, a test suite, or a validation pass may itself run for a long time.
Sessions today are shaped around a bounded, continuous run. When a session reaches the end of its lifetime, the execution environment is torn down. Resuming afterwards starts a fresh environment: installed dependencies, build outputs, caches, and the uncommitted working tree are gone. For a large repository, re-establishing that state can cost more time than the original work, which makes a pause-for-input workflow impractical precisely where it matters most.
Credential lifetime compounds this. Tokens acquired at session start can expire while the session is legitimately idle awaiting a human, so work that resumes successfully may then fail on its next authenticated call.
What is missing
- No supported way for a session to suspend while awaiting human input without losing its execution environment.
- Resuming a session provisions a new environment; there is no guarantee of workspace continuity — dependencies, build artifacts, caches, and uncommitted changes are not preserved.
- No way to steer or redirect a run already in progress; the caller must wait for it to finish or abandon it.
- Session and credential lifetimes are not independently controllable, so an idle session can outlive its own authentication.
- Maximum session lifetime, idle timeout, and workspace retention period are not discoverable before starting work.
Proposed behavior
- A session can enter a suspended state when it needs human input, and be resumed later with its workspace preserved.
- Workspace continuity across suspend and resume is explicit and documented: the caller knows what is retained (working tree, dependencies, caches) and what is not.
- Retention is configurable within documented bounds, so a caller can choose to hold a workspace across a weekend.
- A caller can send additional input, redirect, or cancel an in-progress run without discarding completed work.
- Credentials can be refreshed on resume, so an idle period does not invalidate the session's ability to continue.
- Effective lifetime, idle timeout, and retention values are reported to the caller before work begins.
- If a workspace cannot be preserved, the session says so explicitly rather than silently resuming in an empty environment.
Example scenario
An agent is asked to diagnose and fix a failing integration test in a large repository. It clones, installs dependencies, reproduces the failure, and identifies two viable fixes with different compatibility trade-offs. It asks which to take, then suspends.
Six hours later the requester answers. The session resumes in the same workspace, with dependencies still installed and the reproduction still in place, applies the chosen fix, runs the suite, and opens a pull request. While the suite is running, the requester adds a note asking it to also update the changelog; the agent incorporates it without restarting.
Acceptance criteria
- A session can suspend awaiting input and resume with its workspace intact.
- Workspace retention semantics and limits are documented and discoverable.
- An in-progress run accepts additional input without losing completed work.
- Credential expiry during an idle period does not prevent resumption.
- Loss of workspace state on resume is reported explicitly.
Related
Problem
A realistic engineering task is not a single uninterrupted run. The agent investigates, reaches a decision it should not make alone, asks a question, and waits. The answer may come back in minutes, or the next working day. Meanwhile a build, a test suite, or a validation pass may itself run for a long time.
Sessions today are shaped around a bounded, continuous run. When a session reaches the end of its lifetime, the execution environment is torn down. Resuming afterwards starts a fresh environment: installed dependencies, build outputs, caches, and the uncommitted working tree are gone. For a large repository, re-establishing that state can cost more time than the original work, which makes a pause-for-input workflow impractical precisely where it matters most.
Credential lifetime compounds this. Tokens acquired at session start can expire while the session is legitimately idle awaiting a human, so work that resumes successfully may then fail on its next authenticated call.
What is missing
Proposed behavior
Example scenario
An agent is asked to diagnose and fix a failing integration test in a large repository. It clones, installs dependencies, reproduces the failure, and identifies two viable fixes with different compatibility trade-offs. It asks which to take, then suspends.
Six hours later the requester answers. The session resumes in the same workspace, with dependencies still installed and the reproduction still in place, applies the chosen fix, runs the suite, and opens a pull request. While the suite is running, the requester adds a note asking it to also update the changelog; the agent incorporates it without restarting.
Acceptance criteria
Related
SessionMetadataso persisted sessions can be resumed by id #1730 — surfacing working directory on session metadata so a session can be resumed by id.