Skip to content

[REMOTE-2208] Add --idle-on-fail so failed cloud sessions stay joinable - #14565

Draft
dmichelin wants to merge 1 commit into
masterfrom
factory/remote-2208-idle-on-fail
Draft

[REMOTE-2208] Add --idle-on-fail so failed cloud sessions stay joinable#14565
dmichelin wants to merge 1 commit into
masterfrom
factory/remote-2208-idle-on-fail

Conversation

@dmichelin

Copy link
Copy Markdown
Contributor

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, so IsExecutionReachable still resolves session_ended and follow-up injection still gets 410 Gone. This PR adds the missing client half.

What changed

  • New hidden --idle-on-fail [DURATION] flag (defaults to 15m when passed bare) — the failure counterpart to --idle-on-complete — plumbed through AgentDriverOptions into AgentDriver.
  • Oz harness: a terminal Error conversation 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 by LocalAgentTaskSyncModel, so the run's terminal state and timing are unchanged — only the process lifetime differs. This 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 before this flag existed, so that arm now uses idle_on_fail with 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.

  • The linked issue is labeled ready-to-spec or ready-to-implement.
  • Where appropriate, screenshots or a short video of the implementation are included below (N/A — headless CLI flag with no UI surface).

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 to None (pinning the opt-in contract), and it composes independently with --idle-on-complete.
  • app/src/ai/agent_sdk/driver_tests.rs — 3 tests for third_party_failure_idle_window, pinning the precedence and the back-compat fallback that keeps existing Claude Code failures idling.

The existing IdleTimeoutSender tests already cover the defer/cancel mechanism this reuses.

Commands run:

  • ./script/format
  • cargo clippy -p warp -p warp_cli --all-targets --tests -- -D warnings — clean
  • cargo test -p warp_cli --lib idle_on — 8 passed
  • cargo test -p warp --lib third_party_failure_idle_window — 3 passed

Not run: the full ./script/presubmit suite (whole-workspace build/tests) — this was developed in a cloud sandbox where the full suite is impractical; CI will cover it.

  • I have manually tested my changes locally with ./script/run

End-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

  • Warp Agent Mode - This PR was created via Warp's AI 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.

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>
@cla-bot cla-bot Bot added the cla-signed label Jul 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant