Drag-and-drop image into CLI agent (Claude Code) inserts file path instead of attaching the image

[SagarSDagdu]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there

Describe the bug

When a CLI agent (e.g. Claude Code) is the active foreground process in a Warp tab, dragging an image file (e.g. a screenshot) onto the terminal inserts the file path as text into the agent's prompt, rather than attaching the image as image context.

Pasting the same image with Cmd+V (with the image bytes on the clipboard) attaches the image correctly. The two flows should converge for image files dropped while a CLI agent is active.

https://www.loom.com/share/32b03580946249389be828e15e5a7d8d

To reproduce

1. Open a Warp tab and start a Claude Code session.
2. Take a screenshot (Cmd+Shift+4) so the screenshot file lands on the Desktop.
3. Drag the screenshot file onto the Warp window with the Claude Code session active. Reproduces both when dragging from Finder and when dragging the macOS screenshot preview thumbnail directly.
4. Observe: the file path is typed into Claude Code's prompt as plain text.
5. For comparison, copy the same screenshot to the clipboard (Preview → Edit → Copy, or Cmd+Shift+Ctrl+4 to copy directly), then Cmd+V into the same Claude Code session — the image is attached.

Expected behavior

Drag-and-drop of an image file into a tab with an active CLI agent session should attach the image as image context (the same outcome as the Cmd+V flow), not insert the file path as text.

Operating system (OS)

macOS

Operating system and version

macOS 26.4.1 (25E253)

Current Warp version

v0.2026.04.22.08.46.stable_03

Regression

No, this bug or issue has existed throughout my experience using Warp

Additional context

Quick code trace from a read of the open-source repo:

• `TerminalView::drag_and_drop_files` (`app/src/terminal/view.rs:23754`) gates the image-attach branch on `!is_in_long_running_command` (line 23773). When a CLI agent like Claude Code is running, the active block is long-running, so the attach branch is skipped and the drop falls through to `typed_characters_on_terminal` (line 23830), which writes the path string into the PTY.
• `Input::process_paste_event` (`app/src/terminal/input.rs:9849`) takes a different path for clipboard image bytes — it calls `handle_pasted_image_data`, which does not consult the long-running-command gate. That's why Cmd+V works.
• The downstream `can_attach_on_filepaths_paste_or_dragdrop` (`app/src/terminal/input.rs:9921`) already has an explicit branch that returns `true` when `CLIAgentSessionsModel::is_input_open(...)` is true, so the gating helper is ready for this case — only the upstream long-running-command short-circuit blocks it.

This is not a request to revert #7032 (path-pasting in normal shell input). The proposed scope is narrowly: when a CLI agent session is active for the terminal, route image drops through the existing image-attach pipeline instead of typing the path into the PTY. Outside CLI-agent sessions, drag-drop behavior remains unchanged.

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

Ignore

[warp-for-oss]

@SagarSDagdu

Here's what I found while triaging this issue:

Thanks for the detailed repro. This looks actionable: drag-and-drop image files while a CLI-agent session is active appears to take a different path than clipboard image paste, which explains why Cmd+V can attach while dragging inserts the path text.

Maintainer details

I concluded that dragging an image file into an active CLI-agent session is routed through terminal path insertion instead of the existing image-attachment pipeline..

Triage summary

This looks like an actionable bug in the CLI-agent image attachment flow for drag-and-drop image files. The observed behavior is specific: when a CLI agent is the foreground long-running process, dropping an image file inserts the image file path into the PTY instead of attaching the image, while clipboard image paste can still attach correctly.

Reproducibility

High. The report includes clear macOS steps, a current Warp stable version, a comparison against the working clipboard-image path, and a code path that matches the symptom.

Likely root cause

Current code supports the reporter's diagnosis: TerminalView::drag_and_drop_files checks whether the active block is long-running before attempting image-file attachment. CLI agents run as long-running foreground processes, so the image-file attach branch is skipped and the drop later falls back to inserting escaped paths into the terminal. The downstream image-file attachment helper in Input already allows attachment when CLI-agent input is open, so the problematic gate appears to be upstream of that helper. Clipboard image data follows Input::process_paste_event and does not hit the same drag/drop long-running-command short-circuit.

Relevant files:

• app/src/terminal/view.rs
• app/src/terminal/input.rs
• app/src/terminal/input/cli_agent.rs
• app/src/terminal/view/use_agent_footer/mod.rs

Duplicate check

No matching duplicate found among the provided recent/open issues or a focused open-issue search. #7032 is related historical context for normal terminal path-dropping behavior, but this issue is narrower and not the same request.

Routing notes

Likely areas: CLI-agent rich input/image attachment and terminal drag/drop input handling. STAKEHOLDERS suggests involving owners for CLI-agent rich input/image delivery and terminal input as needed.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz