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