cancel in-progress stuff when cmd-k a conversation by acarl005 · Pull Request #12555 · warpdotdev/warp

acarl005 · 2026-06-12T02:32:32Z

Description

See here: https://warpdev.slack.com/archives/C08KTPNQN65/p1780700091713279?thread_ts=1780640536.267589&cid=C08KTPNQN65

The bug happens with the following scenario:

Ask the agent to run a command, e.g. sleep 10. Let's call this conversation "A".
As the agent is responding but before sleep 10 actually runs, press cmd-k to clear. This starts a new conversation, conversation "B".
The sleep 10 runs in "B".
After sleep 10 completes, the block goes back to "A".

The sleep 10 command should never appear in "B" since it was requested from "A".

This PR has a 2-layer approach to the fix. Either is sufficient for this bug, but implementing both is prudent for robustness.

Cancel in-progress conversation when cmd-k is pressed. It seems that we assumed once a conversation is no longer active in the view, it shouldn't be doing things like executing tool calls anymore. Therefore, we should cancel it if we are hiding the conversation in order to start a new one.
Encode that invariant for executed command by checking, before we execute them, if the active conversation is not the same conversation that it belongs to. If not, cancel the command.

Linked Issue

(partly) fixes #12483

Testing

On this branch, the same repro steps will cancel conversation "A" as soon as cmd-k is pressed.

oz-for-oss · 2026-06-12T02:32:46Z

@acarl005

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

You can view the conversation on Warp.

I completed the review and no human review was requested for 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

MaggieShan

Had a few questions:

Was testing this and can confirm the case for triggering cmd-k while the agent is still generating the command is fixed, but I can still get into a weird state if I cmd-k after the command is running https://www.loom.com/share/0377da7646b046f09530a6b91591108a
Is there a way we can add tests to prevent this from regressing?
Product-wise: I wonder if it'd be a clearer to users if we require a double confirmation before starting a new conversation with cmd-k (similarly to what's done for cmd-enter when already in a conversation) - for users used to cmd-k simply clearing the buffer, it may not be as clear that this would also start a new conversation

…collapsed

acarl005 · 2026-06-17T20:41:28Z

/oz-review

oz-for-oss · 2026-06-17T20:41:46Z

@acarl005

I'm re-reviewing this pull request in response to a review request.

You can view the conversation on Warp.

I completed the review and no human review was requested for 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 adds a Cmd+K cancellation path for the active agent conversation, prevents requested shell commands from executing after another conversation becomes active, and adds regression coverage for agent-driving command states.

Concerns

The Cmd+K cancellation path only runs for conversations whose status is InProgress. Requested commands that are waiting for user confirmation transition the conversation to Blocked while still leaving the pending action live, so clearing into a new conversation can leave the old command/action uncancelled instead of satisfying the PR's intended invariant.
This changes user-facing Cmd+K/agent-view behavior, but the PR description only includes textual testing. For this user-facing change, please include screenshots or a screen recording demonstrating it working end to end.

Verdict

Found: 0 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

oz-for-oss · 2026-06-17T20:45:24Z

+                    .agent_view_state()
+                    .active_conversation_id()
+                {
+                    let is_in_progress = BlocklistAIHistoryModel::as_ref(ctx)


⚠️ [IMPORTANT] This status gate misses pending actions once the conversation is Blocked for user confirmation. A requested command can be queued, fail auto-execution, set the conversation to Blocked, and then Cmd+K will start a new conversation without calling cancel_conversation_progress, leaving the old action live instead of canceling the work being left. Cancel unconditionally for the active conversation or also cover blocked/unfinished-action states.

Actually that case behaves just fine. "blocked" is a fine state. Users can go back to that conversation and approve if they want.

acarl005 · 2026-06-17T21:06:19Z

@MaggieShan

but I can still get into a weird state if I cmd-k after the command is running

Fixed! Needed to check for an additional state. I made sure this case matches the behavior when the command is running and the agent is monitoring it, i.e. it clears the running command's grid.

Is there a way we can add tests to prevent this from regressing?

Added some unit tests, needed to add some new mocks for this.

Product-wise: I wonder if it'd be a clearer to users if we require a double confirmation before starting a new conversation with cmd-k

Ah that's a good Q. My intuition would be not to require double confirmation. We do require it for cmd-enter and ctrl-c which I think makes sense. ctrl-c does a lot of other stuff, e.g. exiting a long-running command, exiting insert mode in Vim keybindings, clearing the input editor, etc. If we didn't require a double-press, it would be super easy to accidentally exit your conversation with ctrl-c. cmd-k is different b/c it isn't as overloaded with other functions. Also, cmd-k is already a pretty destructive action in a normal terminal + shell setup, e.g. in iTerm it deletes the whole screen+scrollback. If users are pressing cmd-k I think we have more confidence in their intent, and the way we handle it in the agent view, starting a new convo (or clearing the grid for the active running command), maps pretty cleanly to the idea of clearing in a normal terminal.

That said, I don't think it's critical to make that change in this PR. I think this change is strictly better than the existing functionality. I'm very open to adding that if people find this too destructive. What do you think?

MaggieShan · 2026-06-17T22:30:38Z

Ah that's a good Q. My intuition would be not to require double confirmation. We do require it for cmd-enter and ctrl-c which I think makes sense. ctrl-c does a lot of other stuff, e.g. exiting a long-running command, exiting insert mode in Vim keybindings, clearing the input editor, etc. If we didn't require a double-press, it would be super easy to accidentally exit your conversation with ctrl-c. cmd-k is different b/c it isn't as overloaded with other functions. Also, cmd-k is already a pretty destructive action in a normal terminal + shell setup, e.g. in iTerm it deletes the whole screen+scrollback. If users are pressing cmd-k I think we have more confidence in their intent, and the way we handle it in the agent view, starting a new convo (or clearing the grid for the active running command), maps pretty cleanly to the idea of clearing in a normal terminal.

That said, I don't think it's critical to make that change in this PR. I think this change is strictly better than the existing functionality. I'm very open to adding that if people find this too destructive. What do you think?

That's a good point on user intent with cmd-k compared to ctrl-c - agreed in that case for keeping the current product behaviour! Also agreed any changes related to this point would be out of scope for this pr 👍

MaggieShan

Thanks for iterating - approving to unblock!

MaggieShan · 2026-06-17T23:08:29Z

                .block_list()
                .active_block()
                .is_agent_monitoring();
+            let is_agent_driving_command = self


nit: can we combine the access to the model and active lock so that we're not acquiring it multiple times?

borrow checker made it a tad awk but done!

acarl005 added the warp:product-quality label Jun 12, 2026

cla-bot Bot added the cla-signed label Jun 12, 2026

acarl005 self-assigned this Jun 12, 2026

This comment was marked as resolved.

Sign in to view

acarl005 requested a review from MaggieShan June 12, 2026 02:36

MaggieShan reviewed Jun 16, 2026

View reviewed changes

acarl005 added 2 commits June 16, 2026 15:43

cancel in-progress stuff when cmd-k a conversation

3f7a10a

prevent weird state if cmd-k pressed while command running but still …

22e978e

…collapsed

acarl005 force-pushed the andy/fix-agent-requested-command-in-wrong-conversation branch from d32f65a to 22e978e Compare June 17, 2026 04:03

acarl005 added 4 commits June 17, 2026 11:46

add some tests

2a6430e

set up a mock stream

70da6b0

one last fix for visibility after clearing

0c5c073

cargo fmt

c10e0a0

oz-for-oss Bot reviewed Jun 17, 2026

View reviewed changes

cargo fmt with correct config

58253eb

acarl005 requested a review from MaggieShan June 17, 2026 21:06

MaggieShan approved these changes Jun 17, 2026

View reviewed changes

reduce locking churn

4f188b6

acarl005 enabled auto-merge (squash) June 18, 2026 01:16

acarl005 merged commit 7070e4d into master Jun 18, 2026
38 of 42 checks passed

acarl005 deleted the andy/fix-agent-requested-command-in-wrong-conversation branch June 18, 2026 01:28

dagmfactory pushed a commit that referenced this pull request Jun 30, 2026

cancel in-progress stuff when cmd-k a conversation (#12555)

43fa000

Uh oh!

Conversation

acarl005 commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Linked Issue

Testing

Uh oh!

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

Uh oh!

Uh oh!

This comment was marked as resolved.

Uh oh!

MaggieShan left a comment

Choose a reason for hiding this comment

Uh oh!

acarl005 commented Jun 17, 2026

Uh oh!

oz-for-oss Bot commented Jun 17, 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!

oz-for-oss Bot Jun 17, 2026

Choose a reason for hiding this comment

Uh oh!

acarl005 Jun 17, 2026

Choose a reason for hiding this comment

Uh oh!

acarl005 commented Jun 17, 2026

Uh oh!

MaggieShan commented Jun 17, 2026

Uh oh!

MaggieShan left a comment

Choose a reason for hiding this comment

Uh oh!

MaggieShan Jun 17, 2026

Choose a reason for hiding this comment

Uh oh!

acarl005 Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

acarl005 commented Jun 12, 2026 •

edited

Loading

oz-for-oss Bot commented Jun 12, 2026 •

edited

Loading

oz-for-oss Bot commented Jun 17, 2026 •

edited

Loading