← Back to Blog

Developers & Code | Jun 15, 2026 | 7 min read

Why Does Drag-and-Drop Fail in Admin VS Code?

By Deepender Yadav

Why Does Drag-and-Drop Fail in Admin VS Code? — Edge Drop Guide

Drag-and-drop into VS Code stops working when VS Code is running as administrator. The user drags a file from Explorer onto the VS Code window, and nothing happens. The file does not open. No error appears. The drag is simply ignored. The same drag works fine when VS Code is running with normal privileges. This is not a VS Code bug; it is a Windows security feature called User Interface Privilege Isolation (UIPI), and it affects every elevated application, not just VS Code.

This guide explains why elevated processes break drag-and-drop, what the workarounds are, and why the right answer is usually to not run elevated. It is written for developers on Windows who occasionally need to run VS Code as administrator and have hit the drag-drop failure. For neighbouring topics, see snippet managers for code: project files win, copying hex dumps and keeping alignment, best clipboard habits for developers in 2026, and copying error logs without taking half the console.

What UIPI is and why it blocks drags

User Interface Privilege Isolation is a Windows security feature introduced in Windows Vista. It prevents lower-privilege processes from sending window messages to higher-privilege processes. The goal is to prevent "shatter attacks" — attacks where a lower-privilege process sends malicious window messages (e.g. WM_DROPFILES, WM_PASTE) to a higher-privilege process to make the higher-privilege process execute arbitrary code.

When VS Code is running as administrator (high integrity level) and Explorer is running with normal privileges (medium integrity level), Windows blocks the drag-and-drop window messages from Explorer to VS Code. The drag is initiated, but the drop target (VS Code) never receives the drop notification, so nothing happens. The same applies to drops from Edge-Drop, Ditto, the Run dialog, and most other non-elevated sources.

The same blocking applies to:

  • Drag-and-drop from non-elevated Explorer, Edge-Drop, or any non-elevated shell.
  • Copy-paste in some configurations (clipboard can cross integrity levels in some Windows versions, but the behaviour is inconsistent and depends on session configuration).
  • Window messages more broadly — custom window messages from non-elevated processes are also blocked.

The feature is documented in Microsoft's UIPI documentation. It is intentional, not a bug.

Why developers run VS Code as administrator

Common reasons developers run VS Code elevated:

  • Writing to C:\Program Files\ or other system directories. Some developers work on system-level code that needs to be tested in-place.
  • Debugging a service. Attaching a debugger to a Windows service requires administrator privileges.
  • Running a script that requires administrator privileges. Build scripts that install drivers, modify the registry, or configure IIS.
  • Using a tool that requires administrator privileges and is invoked from VS Code's terminal. Some legacy tools require admin and pollute the shell.

In most cases, the developer does not need to run VS Code itself elevated. They need to run a specific command elevated, which can be done in a separate elevated terminal or via runas. Running the entire IDE elevated is overkill and introduces the drag-drop failure mode.

The right answer: do not run elevated

For most development work, the right answer is to run VS Code with normal privileges and elevate only the specific commands that need it:

  • Open a separate elevated terminal (right-click Windows Terminal → Run as administrator) for the specific commands that need admin. Run the rest of the workflow in the non-elevated VS Code terminal.
  • Use runas or gsudo for individual commands. gsudo is a community tool that provides a sudo-like experience on Windows, prompting for UAC only for the specific command.
  • Configure the debugger to attach to the service with elevated privileges, rather than running the IDE elevated. Visual Studio Code's debugger supports attaching to a process, and the attach can be done with elevation via a separate elevated process.
  • Modify the project to not require admin. If the project requires admin because it writes to C:\Program Files\, move the build output to a user-writable directory (%LOCALAPPDATA%\MyApp). If it requires admin because of a service, consider running the service as a user-writable test harness during development.

The non-elevated workflow is faster (no UAC prompts), more secure (no risk of a malicious npm package running with admin privileges), and does not break drag-and-drop.

Workarounds when elevation is unavoidable

When VS Code must run elevated, the drag-drop failure can be worked around:

1. Use the file menu instead of drag-drop

File → Open File in VS Code uses a file picker dialog, not drag-drop. The dialog is rendered by VS Code itself and is not subject to UIPI. This is the simplest workaround; it adds one click per file open.

2. Copy the file path instead of dragging

In Explorer, Shift+right-click → Copy as path copies the file path. In VS Code, Ctrl+O opens the file-open dialog, and the path can be pasted. This is faster than navigating the file picker.

3. Use code from an elevated terminal

If the developer has an elevated terminal open (e.g. for running build commands), code path/to/file.txt from that terminal opens the file in VS Code. Because the terminal is elevated, the launch is elevated, and the file opens correctly. This is the fastest workflow when an elevated terminal is already open.

4. Use gsudo to launch VS Code elevated on demand

gsudo allows launching a single command elevated without keeping an elevated shell open. gsudo code opens VS Code elevated, with a UAC prompt. Useful for the specific task that requires elevation; close VS Code when the task is done.

5. Change the integrity level of the source process

It is technically possible to launch Explorer (or another drag source) at high integrity level, which would unblock drags to elevated VS Code. This is not recommended — running Explorer elevated defeats the security purpose of UAC and exposes the system to malware that exploits file associations and shell extensions. Do not do this.

6. Use ChangeWindowMessageFilter (developers only)

For developers writing their own drag source, the ChangeWindowMessageFilterEx API allows a window to opt in to receiving messages from lower-integrity processes. This is the technical fix that VS Code could implement (and some IDEs do), but it requires code changes in the drop target, not the drag source. VS Code does not currently do this; track the VS Code GitHub issues for the current state.

Why this also affects Edge-Drop and other clipboard shelves

Edge-Drop (and other edge-anchored clipboard shelves) uses drag-and-drop via the OS file handle (OLE drag-and-drop, startDrag). When VS Code is elevated and Edge-Drop is not, the drag is blocked by UIPI in the same way that Explorer drags are blocked. The shelf can stage the file, the developer can initiate the drag, but VS Code does not receive the drop.

The workarounds are the same:

  • Run VS Code non-elevated (the right answer).
  • Use code path from an elevated terminal (when elevation is unavoidable).
  • Use the file menu or copy-paste the path (slower but works).

Edge-Drop, like Explorer, is a non-elevated process by default. Running Edge-Drop elevated is not a solution; it would defeat the security model and is not supported.

A note on UAC and clipboard

UAC also affects the clipboard, though the behaviour is more nuanced than for drag-drop. In some Windows configurations, the clipboard can cross integrity levels (a non-elevated copy can be pasted into an elevated app), but the behaviour depends on session configuration and group policy. The reliable behaviour:

  • Copy from non-elevated, paste into elevated: may work, depending on configuration. Often blocked in enterprise environments.
  • Copy from elevated, paste into non-elevated: usually works, because the elevated process has the privileges to write to the clipboard.
  • Both elevated: works.
  • Both non-elevated: works.

For developers who need to copy between elevated and non-elevated processes regularly, the practical rule is: do not run elevated. If elevation is unavoidable, use the file menu or code path for files, and accept that copy-paste may be flaky.

Detecting whether VS Code is elevated

Before debugging a drag-drop failure, it helps to confirm whether VS Code is actually running elevated. The developer's belief that they are running non-elevated is sometimes wrong — a shortcut property, a compatibility shim, or a parent process that was elevated can all cause VS Code to inherit elevation.

To check: in VS Code's integrated terminal, run whoami /groups (Windows) and look for the Mandatory Label line. If it says High Mandatory Level, VS Code is elevated. If it says Medium Mandatory Level, VS Code is running with normal privileges. This is the authoritative check; the title bar does not always show the elevation status.

For a quick visual cue, some developers configure their shell prompt to show elevation status (a red # for elevated, a green $ for non-elevated). This makes elevation obvious at a glance, which prevents the "why is drag-drop not working" debugging session from starting in the first place.

Related reading

Sources

Deepender Yadav
Written by Deepender Yadav · Author & Developer

Deepender Yadav is a B.Tech Computer Science Engineering student and software developer interested in building practical software and open-source projects.

GitHub · LinkedIn

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support

Free · Lightweight · Privacy First
Find us on CodeHype