Use new cloud mode setup UI for local -> cloud handoff UI by harryalbert · Pull Request #9653 · warpdotdev/warp

harryalbert · 2026-04-30T19:38:57Z

Description

We want to use the same new cloud mode setup UI for local -> cloud handoff that we have for regular cloud mode setup. We also want to immediately fork the entire conversation into the new cloud pane before you've actually starting the cloud run.

The main change required to do this was to fork the conversation on-chip-click instead of on-prompt-send (see the corresponding server PR for this issue), as we don't want the forked conversation to get stale if new prompts are sent to the old conversation between clicking the chip and sending a prompt in the cloud mode window.

Screenshots / Videos

https://www.loom.com/share/580624a891d64bec81f9642dda766583

Agent Mode

Warp Agent Mode - This PR was created via Warp's AI Agent Mode

harryalbert · 2026-04-30T19:39:15Z

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

This stack of pull requests is managed by Graphite. Learn more about stacking.

oz-for-oss · 2026-04-30T22:49:31Z

@harryalbert

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I completed the review and posted feedback on this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

oz-for-oss

Overview

This PR moves local-to-cloud handoff to fork on chip click, pre-populates the new cloud pane with the forked conversation, and reuses cloud-mode setup UI/replay suppression for the handoff flow.

Concerns

The diff has compile-blocking Rust issues in the handoff session/input-mode path and the PendingHandoff initializer.
The setup-command flag is still cleared by restored conversation exchanges, so the handoff pane can leave setup mode before the cloud session's startup commands arrive.
The submit path can silently no-op if snapshot upload has not produced a cached prep token.
Manual security pass found no additional security-specific findings in the inlined diff.

Verdict

Found: 2 critical, 2 important, 0 suggestions

Request changes

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

zachbai · 2026-05-04T06:40:39Z

-                        || view_model.is_local_to_cloud_handoff();
+                    let use_queued_prompt = view_model.is_third_party_harness();
                    if use_queued_prompt {
-                        // Non-oz runs and local-to-cloud handoff (REMOTE-1486) runs:


I actually think we should use the queued prompt UI for cloud->cloud handoff for oz, so maybe we should revert this and continue to use queued ui for local -> cloud handoff

zachbai · 2026-05-04T06:42:25Z

+                // shared-session view; otherwise `apply_client_actions` won't reconstruct
+                // UserQuery / ActionResult inputs from the cloud agent's response messages.
+                history.update(ctx, |history, _| {
+                    history.set_viewing_shared_session_for_conversation(*conversation_id, true);


It feels kind of weird that this is done here - shouldn't this be set at the point at which the shared session starts and the cloud mode pane is connected to it?

zachbai · 2026-05-04T06:43:19Z

+        // Only skip the replayed response when we already have a local exchange whose
+        // `server_output_id` matches `request_id`. New exchanges (e.g. the user's first
+        // post-handoff prompt) carry unseen request_ids and must flow through normally.


i don't get this

zachbai · 2026-05-04T06:43:21Z

+        // Only skip the replayed response when we already have a local exchange whose
+        // `server_output_id` matches `request_id`. New exchanges (e.g. the user's first
+        // post-handoff prompt) carry unseen request_ids and must flow through normally.


i don't get this

when would we actually have a local exchagne whose server output id matches the givne request_id that we just got from the server?

zachbai · 2026-05-04T06:45:53Z

-/// duplicate rendering in the AI block path when that optimistic block was actually inserted.
+/// (not replaying historical conversation events) AND the AI block's display query matches an
+/// optimistically rendered user query. The per-query check is important for forked
+/// conversations (e.g. local-to-cloud handoff) where the conversation's first exchange comes


I don't get this- "the conversations first exchange comes from the source conversation and must remain visible"?

zachbai · 2026-05-04T06:46:28Z


+        // Re-render when the cloud agent transitions through setup phases so the response
+        // footer toggles correctly with `is_cloud_agent_pre_first_exchange`. Each event below
+        // toggles that helper's output.


"toggles that helper's output" means what?

zachbai · 2026-05-04T06:47:57Z

+                        | AmbientAgentViewModelEvent::NeedsGithubAuth
+                        | AmbientAgentViewModelEvent::HarnessCommandStarted
+                ) {
+                    ctx.notify();


This seems pretty inefficient- it doesn't seem right to trigger render for every AI block based on status updates at the task level. Can we either unsubscribe after a certain point or listen to a more granular event

cla-bot Bot added the cla-signed label Apr 30, 2026

harryalbert changed the base branch from harry/remote-1486-implement-local-cloud-handoff to graphite-base/9653 April 30, 2026 20:10

harryalbert force-pushed the harry/remote-1519-make-ui-better-for-local-cloud-handoff branch from ce2f268 to b0a73ac Compare April 30, 2026 21:47

harryalbert changed the base branch from graphite-base/9653 to harry/remote-1486-implement-local-cloud-handoff April 30, 2026 21:47

harryalbert force-pushed the harry/remote-1519-make-ui-better-for-local-cloud-handoff branch from b0a73ac to a1189d6 Compare April 30, 2026 21:58

harryalbert force-pushed the harry/remote-1486-implement-local-cloud-handoff branch from 48ed3c0 to 9311573 Compare April 30, 2026 22:43

harryalbert force-pushed the harry/remote-1519-make-ui-better-for-local-cloud-handoff branch from a1189d6 to 0852c52 Compare April 30, 2026 22:43

harryalbert changed the title ~~write product and tech specs~~ Improve local -> cloud handoff UI Apr 30, 2026

harryalbert changed the title ~~Improve local -> cloud handoff UI~~ Use new cloud mode setup UI for local -> cloud handoff UI Apr 30, 2026

harryalbert marked this pull request as ready for review April 30, 2026 22:49

oz-for-oss Bot reviewed Apr 30, 2026

View reviewed changes

Comment thread app/src/terminal/shared_session/viewer/terminal_manager.rs

Comment thread app/src/workspace/view.rs

Comment thread app/src/terminal/view.rs

Comment thread app/src/terminal/view/ambient_agent/model.rs Outdated

harryalbert requested a review from zachbai May 2, 2026 00:17

harryalbert force-pushed the harry/remote-1486-implement-local-cloud-handoff branch from 9311573 to eea298a Compare May 2, 2026 01:09

harryalbert force-pushed the harry/remote-1519-make-ui-better-for-local-cloud-handoff branch 2 times, most recently from 53f23d7 to a8f005f Compare May 2, 2026 20:42

harryalbert force-pushed the harry/remote-1486-implement-local-cloud-handoff branch from eea298a to 3e9b09c Compare May 2, 2026 20:42

make UI better for local cloud handoff

ed2d37d

harryalbert force-pushed the harry/remote-1519-make-ui-better-for-local-cloud-handoff branch from a8f005f to ed2d37d Compare May 3, 2026 19:56

harryalbert force-pushed the harry/remote-1486-implement-local-cloud-handoff branch from 3e9b09c to 305a73a Compare May 3, 2026 19:56

harryalbert mentioned this pull request May 3, 2026

open local->cloud mode conversation in the same pane #9988

Open

1 task

zachbai reviewed May 4, 2026

View reviewed changes

Conversation

harryalbert commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Screenshots / Videos

Agent Mode

Uh oh!

harryalbert commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oz-for-oss Bot commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oz-for-oss Bot left a comment

Choose a reason for hiding this comment

Overview

Concerns

Verdict

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

harryalbert commented Apr 30, 2026 •

edited

Loading

harryalbert commented Apr 30, 2026 •

edited

Loading

oz-for-oss Bot commented Apr 30, 2026 •

edited

Loading