Skip to content

Fix cmd-enter block attachment not starting a new conversation#12433

Closed
MaggieShan wants to merge 1 commit into
masterfrom
oz/fix-cmd-enter-block-attach-new-conversation
Closed

Fix cmd-enter block attachment not starting a new conversation#12433
MaggieShan wants to merge 1 commit into
masterfrom
oz/fix-cmd-enter-block-attach-new-conversation

Conversation

@MaggieShan

Copy link
Copy Markdown
Contributor

Description

Pressing cmd-enter while a block (or text) is selected stopped starting a new conversation with that block attached as context. The block-attach flow now works again in a single press.

Root cause

A recent change (should_start_new_conversation_for_keybinding) gates keybinding-triggered /agent / /new behind a second-press confirmation when the user is already in an active, non-empty conversation. This guards against accidental conversation resets from reflexive keypresses, but it also intercepted the deliberate "select a block → cmd-enter" flow: the first press only armed the confirmation rather than starting the conversation, so the block was never attached.

Fix

In Input::execute_slash_command, when the user has deliberately attached context (selected blocks, selected text, image/file attachments, or a document) we now skip the confirmation and start the new conversation in a single step. A new BlocklistAIContextModel::has_pending_user_context() helper centralizes that check. Auto-attached agent-view blocks are intentionally excluded since they are not a deliberate user selection. The muscle-memory protection is preserved for the empty-handed case.

Linked Issue

  • 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.

Testing

Added unit tests for has_pending_user_context covering the default (empty) state and the pending-block, pending-selected-text, and pending-attachment cases. cargo check -p warp --tests and cargo clippy -p warp --lib -- -D warnings both pass.

Note: the full test binary could not be linked in the sandbox environment due to a memory limit (the linker was OOM-killed), so the new tests were validated for compilation via cargo check --tests but not executed here.

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

Agent Mode

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

Conversation: https://staging.warp.dev/conversation/c4254450-1bca-436d-a75d-48d7b2f5094d
Run: https://oz.staging.warp.dev/runs/019eae75-a9f0-784c-923e-475937db7038

This PR was generated with Oz.

A recent change gated keybinding-triggered `/agent` and `/new` behind a
second-press confirmation when the user is already in an active, non-empty
conversation. This protects against accidental conversation resets, but it
also broke the common flow of selecting a block (or text) and pressing
`cmd-enter` to start a new conversation with that block attached: the first
press only armed the confirmation instead of starting the conversation.

When the user has deliberately attached context (selected blocks, selected
text, image/file attachments, or a document), their intent to start a new
conversation is unambiguous, so we skip the confirmation and proceed in a
single step. The muscle-memory protection is preserved for the empty-handed
case.

Co-Authored-By: Oz <oz-agent@warp.dev>
@cla-bot cla-bot Bot added the cla-signed label Jun 9, 2026
@MaggieShan MaggieShan closed this Jun 11, 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