[REMOTE-2208] Add --idle-on-fail so failed cloud sessions stay joinable - #14565
Draft
dmichelin wants to merge 1 commit into
Draft
[REMOTE-2208] Add --idle-on-fail so failed cloud sessions stay joinable#14565dmichelin wants to merge 1 commit into
dmichelin wants to merge 1 commit into
Conversation
A shared session is only reachable while the agent process hosting it is alive. Today an Oz run that ends in a terminal failure resolves its run exit immediately, the process tears down, and session-sharing marks the session ended -- so a failed run's session is unreachable from the web/wasm client no matter what the server does afterwards. That makes server-side post-failure session retention (REMOTE-2208) reachable only in name: the server can preserve the sandbox, but there is no live host to attach to. This adds the missing client half. - New hidden `--idle-on-fail [DURATION]` flag (15m when passed bare), the failure counterpart to `--idle-on-complete`, plumbed through AgentDriverOptions into AgentDriver. - Oz harness: a terminal Error status now defers the run exit by idle_on_fail instead of exiting immediately, keeping the session hosted for inspection and follow-up. The failure is still reported to the server immediately, so the run's terminal state is unchanged. Deliberately does not fall back to idle_on_complete -- the success window must not silently extend failed runs. - Third-party harnesses: a Failed CLI session already idled for idle_on_complete, so that arm now uses idle_on_fail with a fallback to the success window rather than regressing those runs to an immediate exit. Follow-up activity cancels the pending timer through the existing generation counter, so a user who responds during the window keeps the run alive. Opt-in: with the flag absent every path behaves exactly as it does today. Testing: 4 new CLI parsing tests (bare flag default, explicit duration, opt-in default of None, independence from --idle-on-complete) and 3 unit tests for the third-party fallback policy. `cargo fmt` and `cargo clippy -p warp -p warp_cli --all-targets --tests -- -D warnings` are clean. Co-Authored-By: Warp <agent@warp.dev> Co-Authored-By: Oz <oz-agent@warp.dev>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
A shared session is only reachable while the agent process hosting it is alive. Today an Oz run that ends in a terminal failure resolves its run exit immediately, the process tears down, and session-sharing marks the session ended — so a failed run's session is unreachable from the web/wasm client no matter what the server does afterwards.
That makes server-side post-failure session retention (REMOTE-2208) reachable only in name: warp-server can preserve the sandbox and hold the execution in
RETAINED, but there is no live host to attach to, soIsExecutionReachablestill resolvessession_endedand follow-up injection still gets410 Gone. This PR adds the missing client half.What changed
--idle-on-fail [DURATION]flag (defaults to15mwhen passed bare) — the failure counterpart to--idle-on-complete— plumbed throughAgentDriverOptionsintoAgentDriver.Errorconversation status now defers the run exit byidle_on_failinstead of exiting immediately, keeping the session hosted for inspection and follow-up. The failure is still reported to the server immediately byLocalAgentTaskSyncModel, so the run's terminal state and timing are unchanged — only the process lifetime differs. This deliberately does not fall back toidle_on_complete; the success window must not silently extend failed runs.FailedCLI session already idled foridle_on_completebefore this flag existed, so that arm now usesidle_on_failwith a fallback to the success window (third_party_failure_idle_window) rather than regressing those runs to an immediate exit.Follow-up activity cancels the pending timer through the existing generation counter, so a user who responds during the window keeps the run alive.
Opt-in: with the flag absent, every path behaves exactly as it does today.
How it fits together: the warp-server side of REMOTE-2208 emits this flag at dispatch when the run's cloud environment opts into post-failure retention, and records a marker on the execution so it only retains runs whose client will actually keep hosting the session. This PR must land (and reach the bundled sandbox CLI) before the server flag is enabled.
Linked Issue
REMOTE-2208 — configurable extended session lifetime for failed cloud agents.
ready-to-specorready-to-implement.Testing
Automated coverage added:
crates/warp_cli/src/lib_tests.rs— 4 parsing tests: bare flag resolves to the 15m default, explicit duration parses, the flag defaults toNone(pinning the opt-in contract), and it composes independently with--idle-on-complete.app/src/ai/agent_sdk/driver_tests.rs— 3 tests forthird_party_failure_idle_window, pinning the precedence and the back-compat fallback that keeps existing Claude Code failures idling.The existing
IdleTimeoutSendertests already cover the defer/cancel mechanism this reuses.Commands run:
./script/formatcargo clippy -p warp -p warp_cli --all-targets --tests -- -D warnings— cleancargo test -p warp_cli --lib idle_on— 8 passedcargo test -p warp --lib third_party_failure_idle_window— 3 passedNot run: the full
./script/presubmitsuite (whole-workspace build/tests) — this was developed in a cloud sandbox where the full suite is impractical; CI will cover it../script/runEnd-to-end manual verification is intentionally deferred: exercising this flag requires a sandboxed cloud run whose environment has opted into post-failure retention, which needs the paired warp-server change enabled. Recommend validating on staging once both sides are in place, by forcing a run to fail and confirming the session page stays joinable for the configured window.
Agent Mode
Conversation: https://staging.warp.dev/conversation/34c0986b-759f-4d02-bb41-f27688c6af8f
Run: https://oz.staging.warp.dev/runs/019fb578-8695-7deb-b457-0f47dd78a41c
Plans:
This PR was generated with Oz.