[BUG] Drag and drop not working in VS Code extension chat panel (works in terminal CLI)

Adding a +1 in the hope this gets fixed asap

Absolutely needed. +1

I dont want to pay 200$ for DX like this. Cursor has this from day 0, why you just cant vibe code this as all other CC parts?

Any update on this issue?

+1.

+1 it is strange not having such basic feature this late into the game

+1
Other solution : i use Claude in IDE "BLACKBOX AI" it's working with this

any update?

Why the hell this bug even happened!

+1 please fix

+1 — repro on macOS, drag-drop in the sidebar is unreliable: sometimes no overlay appears, sometimes the overlay appears but drop does nothing.

Specific use case: working with Office files (.xlsx/.docx/.pptx) referenced in chat via a custom MCP extractor. Path-typing workaround works, but sidebar drag-drop is the natural UX.

Note: Anthropic's recently-released Claude for Excel / Word / PowerPoint add-ins are a separate product and do not address this — they put Claude inside Office apps rather than letting Office files into Claude Code.

Totally this is the most frustrating part of moving from cursor, really miss that

Please fix

Drag the file, press SHIFT before drop - works.

Drag the file, press SHIFT before drop - works.

Nope

> Drag the file, press SHIFT before drop - works. Nope

Watch

https://github.com/user-attachments/assets/960e8272-0ec7-44bd-9f4b-492b5d28f585

@vishnyo what VS Code version and OS is it?

@vishnyo what VS Code version and OS is it?

<img width="1716" height="1012" alt="Image" src="https://github.com/user-attachments/assets/479d33fa-bc11-4014-8c5e-a3771a5d425c" />

<img width="354" height="482" alt="Image" src="https://github.com/user-attachments/assets/2d2a8171-d910-4f30-a9dd-8c7066a94ee1" />

<img width="724" height="1148" alt="Image" src="https://github.com/user-attachments/assets/9be10696-6d57-48e0-86cc-eccf4b8b4b09" />

> @vishnyo what VS Code version and OS is it?

Must only work on MacOS. Because it's 100% not working in Windows / WSL 2. I can see the chat interface reacting to the SHIFT + DRAG UX, but on drop no files are added to the chat interface. RIP.

Version: 1.123.0 (user setup)
Commit: 6a44c352bd24569c417e530095901b649960f9f8
Date: 2026-06-03T11:29:03+02:00
Electron: 42.2.0
ElectronBuildId: 14159160
Chromium: 148.0.7778.97
Node.js: 24.15.0
V8: 14.8.178.14-electron.0
OS: Windows_NT x64 10.0.26200

Identifier
anthropic.claude-code
Version
2.1.168
Last Updated
21 hours ago

I confirmed that on Mac, file paths can be pasted by drag & drop.
It works from both the sidebar and the tabs.
There is a trick to it:

1. Drag the file
2. Move it over the paste area
3. Once over the area, press and hold Shift
4. Drop it

- Mac
Apple M4 Pro
Tahoe 26.5.1

- Claude Code for VS Code
2.1.181

https://github.com/user-attachments/assets/49765c68-6d32-40be-a13c-e4564a36443e

I've found that the drag-and-drop feature specifically doesn't work when using the Remote SSH extension, and working with a codebase which is on the remote machine.
So if I am using a codebase which is on the remote machine, drag-and-drop doesn't work. I have to manually @ to add context.
If I'm using a codebase which is local, drag-and-drop works perfectly.

Identifier
ms-vscode-remote.remote-ssh
Version
0.124.0

Identifier
anthropic.claude-code
Version
2.1.197

Version: 1.126.0
Commit: 7e7950df89d055b5a378379db9ee14290772148a
Date: 2026-06-23T01:46:13Z
Electron: 42.2.0
ElectronBuildId: 14159160
Chromium: 148.0.7778.97
Node.js: 24.15.0
V8: 14.8.178.14-electron.0
OS: Darwin arm64 25.5.0

MacBook Air
15-inch, M4, 2025
16GB

I think I've found the root cause in the extension bundle and verified a fix locally.

Root cause

In the webview bundle (webview/index.js, v2.1.199), dropped files arrive via the drag's
dataTransfer as URI strings under the resourceurls and codeeditors types. Both branches
funnel each URI through the same converter function (minified as uQe):

async function uQe(e, t) {
  if (!e.trim()) return null;
  let i = e.trim();
  if (!i.startsWith("file://")) return null;   // ← the bug
  i = decodeURIComponent(i.substring(7));
  if (t && i.startsWith(t)) {
    i = i.slice(t.length);
    if (i.startsWith("/")) i = i.slice(1);
  }
  return i;
}

It only accepts file:// URIs and silently returns null for anything else. In a Remote SSH
window, resources dragged from the VS Code explorer carry vscode-remote://ssh-remote+<host>/path
URIs, not file:// URIs — so every drop is discarded with no error and no visual feedback,
which matches the reported behavior exactly. Local workspaces produce file:// URIs, which is
why drag-and-drop works there.

This likely explains at least #21044 (Remote-SSH) among the issues consolidated here.
Note that @ mentions are unaffected because they resolve through the extension host (running
on the remote), which reads files via the VS Code API directly — the drop path is the only place
where resource URIs cross into the webview as strings.

Verified fix

I patched the installed bundle on my remote machine
(~/.vscode-server/extensions/anthropic.claude-code-2.1.199-linux-x64/webview/index.js) to strip
the vscode-remote://<authority> prefix and fall through to the existing file:// logic:

async function uQe(e, t) {
  if (!e.trim()) return null;
  let i = e.trim();
  if (i.startsWith("vscode-remote://")) {
    let rp = i.indexOf("/", "vscode-remote://".length);
    if (rp === -1) return null;
    i = "file://" + i.substring(rp);           // strip scheme + authority
  }
  if (!i.startsWith("file://")) return null;
  // ... rest unchanged
}

After Developer: Reload Window, drag-and-drop from the explorer into the chat works over
Remote SSH — the dropped file is added as context, same as in a local workspace. The existing
workspace-root relativization and URL-decoding continue to apply since the converted URI reuses
the original code path. In the real source this is probably better expressed by parsing with
vscode.Uri and accepting the vscode-remote scheme rather than string-prefix matching.

Environment: Claude Code extension 2.1.199 (linux-x64 remote), Remote-SSH 0.124.0,
VS Code 1.126.0 on macOS (arm64) → Ubuntu remote.

I developed a vscode extension plugin [Drag File to Claude Code Session], which is currently available for testing.
Installation Method 1: Install from VS Code Marketplace. Press Ctrl+Shift+X to open the extension panel, search for "Drag File to Claude Code Session", and click Install.

**Another root cause, affecting local (non-remote) drops: the handler reads dataTransfer path data after an await, when the drag data store is already cleared**

This is independent of the Remote-SSH vscode-remote:// scheme issue reported above — both discard drops silently.

In webview/index.js, the chat drop handler processes attachments first and only then reads the path data used for @path mention insertion (minified names from 2.1.185; 2.1.207 from the marketplace is structurally identical):

async function Me($) {
  // ...guards...
  let De = $.dataTransfer?.files;
  if (De && De.length > 0) {
    let {attachments: At, unsupportedFiles: Ri} = await bR(De);  // ← await: reads file contents as data URLs
    if (At.length > 0) p((so) => [...so, ...At]);
    J(Ri);                                                       // "Unsupported file type" toast
  }
  let gt = $.dataTransfer?.items;                                // ← read AFTER the await
  if (!gt) return;
  await OTt(gt, e.cwd.value, (At) => { a.current?.insertAtMention(`@${At}`, !1) });
}

Per the HTML drag-and-drop spec, the drag data store is only readable synchronously during drop event dispatch. Once the handler yields at await bR(De), dataTransfer.items is empty and getData() returns "". So whenever a drag carries file content (.files non-empty), the @path insertion branch (OTt, which reads the resourceurls/codeeditors string items) is guaranteed to run against an empty item list and silently does nothing.

Observable symptoms this explains:

• Drop a non-attachable file (e.g. .zip): "Unsupported file type" toast, and no @path is ever inserted even though the drag carried the path.
• Drop a supported file: it attaches as content, but the path-mention branch still silently no-ops.
• Drags where .files is empty (plain DOM drags on some platforms) skip the await, reach items synchronously, and work — which is why behavior looks inconsistent across platforms/drag sources in this thread.

Fix: snapshot the string data synchronously at the top of the handler — e.g. const ru = $.dataTransfer.getData("resourceurls"), ce = $.dataTransfer.getData("codeeditors") (or getAsString callbacks registered before any await) — then process attachments.

Verified fix: I patched my installed bundle to snapshot resourceurls/codeeditors via getData() before the await and insert the mentions from the snapshot; after Reload Window, Shift+drag from the Explorer sidebar now inserts @path correctly, including for .zip files that previously only produced the error toast.

Environment: anthropic.claude-code 2.1.185 (running in Cursor, macOS arm64); same handler code confirmed present in the 2.1.207 VSIX from the marketplace.

In my windows i have noticed drag drop fails when connected to a remote ssh, but not when i use it locally.
EVEN THE DRAG DROP EXTENSION BY @shawnli1024 dosent seem to work in remote sshs

In my windows i have noticed drag drop fails when connected to a remote ssh, but not when i use it locally. EVEN THE DRAG DROP EXTENSION BY @shawnli1024 dosent seem to work in remote sshs

Could you check the Output panel in VS Code? Open it with Ctrl+Shift+U, then select "Drag File to Claude Code" from the dropdown at the top-right. Look for a line like [DragCC] Starting ... with python. — this tells us which helper script is being used. If you see [DragCC] Unsupported environment or No X11 DISPLAY is available, it means the extension is running on the remote Linux side instead of your local Windows machine.

> In my windows i have noticed drag drop fails when connected to a remote ssh, but not when i use it locally. EVEN THE DRAG DROP EXTENSION BY @shawnli1024 dosent seem to work in remote sshs Could you check the Output panel in VS Code? Open it with Ctrl+Shift+U, then select "Drag File to Claude Code" from the dropdown at the top-right. Look for a line like [DragCC] Starting ... with python. — this tells us which helper script is being used. If you see [DragCC] Unsupported environment or No X11 DISPLAY is available, it means the extension is running on the remote Linux side instead of your local Windows machine.

<img width="855" height="138" alt="Image" src="https://github.com/user-attachments/assets/d0efe3df-f954-42ea-bf9b-82dfcd1b3863" />

> > In my windows i have noticed drag drop fails when connected to a remote ssh, but not when i use it locally. EVEN THE DRAG DROP EXTENSION BY @shawnli1024 dosent seem to work in remote sshs > > > Could you check the Output panel in VS Code? Open it with Ctrl+Shift+U, then select "Drag File to Claude Code" from the dropdown at the top-right. Look for a line like [DragCC] Starting ... with python. — this tells us which helper script is being used. If you see [DragCC] Unsupported environment or No X11 DISPLAY is available, it means the extension is running on the remote Linux side instead of your local Windows machine. <img alt="Image" width="855" height="138" src="https://private-user-images.githubusercontent.com/52234042/622595297-d0efe3df-f954-42ea-bf9b-82dfcd1b3863.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODQxOTUxOTcsIm5iZiI6MTc4NDE5NDg5NywicGF0aCI6Ii81MjIzNDA0Mi82MjI1OTUyOTctZDBlZmUzZGYtZjk1NC00MmVhLWJmOWItODJkZmNkMWIzODYzLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA3MTYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNzE2VDA5NDEzN1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTRlNjM5YWVkZDdjMWIxNWUxNmVhMzEzNjNjMGQ5OGQxNjkzNmMxMDI1YjdkM2IzY2E4ZTZlNzI2NDZhMTlhOTEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.r2NyRv73ttDc1IETdPXN2OMs2_yM8-FVs7ESxPUQPn0">

I can't get the reason by the message of image. Then there 2 ways , 1-you can fix this bug by yourself and the repo is https://github.com/shawnli1024/drag_file_to_claude_code_session; 2-Just wait, I need to set up the environment and reproduce this bug. Angway, I hope you can chosse 1 and contribute your strength for this tool.

+1
I am on the 2.1.217 version of the Claude Code for VS Code extension . I was asked to evaluate Claude for my company as a potential replacement for Github Copilot. I am shocked to see that such a simple scenario (drag a file from the Explorer window of VS Code) failed .

My assessment overall - Claude is good. However , Claude's usability is significantly behind Github Copilot when it comes to VS Code. Therefore not going to recommend Claude in the foreseeable future.

> > > In my windows i have noticed drag drop fails when connected to a remote ssh, but not when i use it locally. EVEN THE DRAG DROP EXTENSION BY @shawnli1024 dosent seem to work in remote sshs > > > > > > Could you check the Output panel in VS Code? Open it with Ctrl+Shift+U, then select "Drag File to Claude Code" from the dropdown at the top-right. Look for a line like [DragCC] Starting ... with python. — this tells us which helper script is being used. If you see [DragCC] Unsupported environment or No X11 DISPLAY is available, it means the extension is running on the remote Linux side instead of your local Windows machine. > > > <img alt="Image" width="855" height="138" src="https://private-user-images.githubusercontent.com/52234042/622595297-d0efe3df-f954-42ea-bf9b-82dfcd1b3863.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODQxOTUxOTcsIm5iZiI6MTc4NDE5NDg5NywicGF0aCI6Ii81MjIzNDA0Mi82MjI1OTUyOTctZDBlZmUzZGYtZjk1NC00MmVhLWJmOWItODJkZmNkMWIzODYzLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA3MTYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNzE2VDA5NDEzN1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTRlNjM5YWVkZDdjMWIxNWUxNmVhMzEzNjNjMGQ5OGQxNjkzNmMxMDI1YjdkM2IzY2E4ZTZlNzI2NDZhMTlhOTEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.r2NyRv73ttDc1IETdPXN2OMs2_yM8-FVs7ESxPUQPn0"> I can't get the reason by the message of image. Then there 2 ways , 1-you can fix this bug by yourself and the repo is https://github.com/shawnli1024/drag_file_to_claude_code_session; 2-Just wait, I need to set up the environment and reproduce this bug. Angway, I hope you can chosse 1 and contribute your strength for this tool.

I am working on it

+1

Running into this too, in a Dev Container rather than Remote-SSH.

Setup: VS Code on a Windows host, workspace open in a Linux Dev Container, Claude Code extension 2.1.220. Shift-dragging a file from the Explorer into the chat shows the "Drop to attach as context" overlay, but nothing actually gets attached and no path is inserted. No error either, it just silently does nothing. Same in the sidebar and in an editor tab.

Looks like the same problem as #21044, which was for Remote-SSH and got auto-closed for inactivity. So it's at least Remote-SSH and Dev Containers affected, and it doesn't seem Cursor-specific, plain VS Code here.

I'm hitting this problem too on Linux - very surprising that such basic drag and drop functionality is not available after migrating from Copilot. @shawnli1024 thanks for your work on the extension, but v1.1.5 doesn't work for me under the following config, presumably because of Wayland if I understand your readme correctly?

Claude Code for VS Code 2.1.220
VSCode 1.130.0 (Electron 42.6.0, Chromium 148.0.7778.280, Node 24.18.0)
Ubuntu 26.04 (Gnome 50, Wayland)

+1

+1, still happening in Cursor with the Claude Code extension on macOS (Apple Silicon).

I'd love to be able to drag in a path

Environment

• Claude Code extension: anthropic.claude-code 2.1.283 (darwin-arm64)
• Claude Code CLI: 2.1.282
• Cursor: 3.22.7 (VS Code 1.128.0, commit 37076c6, built 2026-09-24)
• Electron 42.10.0 / Chromium 148.0.7778.280
• macOS: 15.6.1 Sequoia (24G90)
• Hardware: MacBook Pro (MacBookPro18,2), Apple M1 Max, 32 GB

Still reproducing on a fully local macOS setup — no remote/WSL/Dev Container involved,
so this is not the vscode-remote:// URI variant tracked in #92403.

Environment

• macOS 27.0 (build 26A428), Apple Silicon
• VS Code 1.140.0
• Extension: anthropic.claude-code-2.1.287-darwin-arm64
• Local workspace, no remote extension host

What happens

Shift+dragging a file from an open editor tab (or from the Explorer) onto the chat
input succeeds roughly every other attempt. There is no visible difference between a
successful and a failed drop: same source file, same drop point, same modifier timing.
When it fails, nothing is attached and no error appears anywhere — not in the chat, not
in the extension output channel.

Things I ruled out, since the thread so far only has +1s and no repro details:

• Dropping over the input field itself rather than the message history — no change.
• Holding Shift from before the drag starts until after release — no change.
• Clicking the input to focus it first, then dragging — no change.
• Pausing over the input for ~1s before releasing — no change.
• Dragging slowly — no change.

The intermittency with identical inputs points at a race in the drop handling rather
than at a wrong drop target or modifier handling.

Drag & drop itself is fine at the OS and VS Code level

Dragging the same file into the VS Code integrated terminal inserts the quoted absolute
path every single time, with or without Shift. So the drag reaches VS Code reliably;
only the chat webview drops it.

@mic-2000 , I had same issue, downgrading only one VS Code version below the issue is not there, so I'm sticking with 1.39.1 until this is fixed on 1.140+

@mic-2000 , I had same issue, downgrading only one VS Code version below the issue is not there, so I'm sticking with 1.39.1 until this is fixed on 1.140+

This fixed the issue for me too.

+1 , same bug. macOS Tahoe 26.7.1

Still reproducing on the current extension build.

Environment

• Claude Code extension anthropic.claude-code 2.1.296 (darwin-arm64)
• VS Code 1.141.0, macOS 27.0.1, Apple Silicon, local workspace (no remote)
• Claude Code opened as an editor tab

Steps

1. Drag a file from the VS Code Explorer onto the Claude Code chat input.
2. Hold Shift over the panel: the editor split overlay disappears, so the drop reaches the webview.
3. Release.

Result: no @path is inserted into the input and no error is shown.

Notes from the 2.1.296 bundle (webview/index.js)

• The drop handler is unchanged from the one analyzed by wwoland above. It awaits processing of dataTransfer.files and only then reads dataTransfer.items, where the resourceurls / codeeditors entries carrying the path live. By then the drag data store is no longer readable. Starting the items extraction before the first await should fix it.
• The downgrade reports above (VS Code 1.139.1 works, 1.140+ fails) would fit if VS Code 1.140 started populating dataTransfer.files for Explorer drags, which sends every Explorer drop through that await. I have not verified this.
• Separately, the handler returns early with no feedback while a response is streaming or a permission prompt is pending, so drops in those states are discarded silently too.

They mentioned that this was fixed in [v2.1.300], but the issue still persists on Windows when using the Claude Code extension in the VS Code UI.

For now, I’m staying on VS Code 1.139.1, as this issue occurs in versions 1.140 and later.