Cannot Paste Into an Admin Window

Cannot paste into an admin window is one of the most consistently confusing Windows problems because the symptom looks like a clipboard bug but is actually a security feature. Windows blocks clipboard transfer — and drag-and-drop, and certain other shell interactions — between processes running at different integrity levels. A normal process cannot paste into an elevated (admin) process, and an elevated process cannot paste into a normal one in some configurations. This is called UIPI (User Interface Privilege Isolation), and it is the same mechanism that prevents a low-integrity process from sending keystrokes to a high-integrity process.

This guide explains why the block exists, when it applies, and the three practical workarounds. For related problems, see paste works in Word but not in a browser for the inverse mismatch case, Ctrl+V inserts a letter V for a different keyboard symptom, and the broader Win+V not working on Windows 11: 9 fixes and Win+V Says 'Nothing Here'? How to Fix Clipboard History on Windows 11 guides.

What UIPI is and why it exists

UIPI is a Windows security feature introduced with Windows Vista. It enforces that a lower-integrity process cannot send window messages to a higher-integrity process. The goal is to prevent a "shatter attack" — a class of exploit where a malicious low-integrity process sends crafted messages to a high-integrity process (like an elevated command prompt or a security tool) to make it execute arbitrary code.

The clipboard is one of the channels that UIPI restricts. A normal-integrity process can write to the clipboard, but an elevated process will not receive the clipboard update message and will not see the new content. The block is silent: there is no error message, no dialog, no log entry. The paste simply does nothing.

The same restriction applies to drag-and-drop. Dragging a file from a normal Explorer window into an elevated app does not work, and dragging a file from an elevated Explorer window into a normal app does not work either.

When the block applies

The block applies whenever the source and target processes are at different integrity levels. The most common scenarios:

• Copying from a normal app and pasting into an elevated command prompt. The cmd window was launched with "Run as administrator."
• Copying from a normal app and pasting into an elevated PowerShell window. Same as above.
• Copying from a normal app and pasting into an elevated registry editor. regedit was launched with "Run as administrator."
• Copying from a normal app and pasting into an elevated third-party tool. Examples include elevated Task Manager, elevated Sysinternals tools, and elevated installers.
• Dragging a file from a normal Explorer window into an elevated app. Same UIPI boundary.
• Dragging a file from a clipboard manager (running normally) into an elevated app. This is a common Edge-Drop and Ditto pain point. See dragging out of a clipboard app into an elevated window.

The block does not apply when both processes are at the same integrity level — both normal or both elevated. The block also does not apply to file-system operations: a normal process can write to a file that an elevated process then reads.

Workaround 1: run both sides elevated

The most direct workaround is to run both the source and target processes at the same integrity level. If the target is elevated (the elevated cmd window), elevate the source as well.

To elevate the source:

1. Right-click the source app's shortcut or Start menu entry.
2. Choose Run as administrator.
3. Confirm the UAC prompt.
4. Copy from the now-elevated source app.
5. Paste into the elevated target. It should work.

This is the cleanest workaround when the source is a single app and the target is a single elevated window. It becomes inconvenient when the source is a browser with many tabs open — elevating a browser is generally not recommended for security reasons.

Workaround 2: use a file as a bridge

Because the UIPI block does not apply to file-system operations, a file can carry content across the integrity boundary. The pattern:

1. Copy the content from the normal source.
2. Paste it into a temporary file (e.g., clip.txt on the Desktop).
3. In the elevated target, read the file.

For command-line targets, this is straightforward:

# In the elevated PowerShell window, read the file
Get-Content -Path "$env:USERPROFILE\Desktop\clip.txt" | Set-Clipboard

After this, the elevated process has the content on its own clipboard and can paste normally.

For non-command-line targets (an elevated GUI app), the file can be opened directly if the app supports it, or the content can be copied manually from the file.

Workaround 3: use Win+V history

Win+V history is hosted by the Clipboard User Service (cbdhsvc), which runs at medium integrity level. Because cbdhsvc is the actual holder of the clipboard data, an elevated process can sometimes read from Win+V even when it cannot read from the live clipboard. The behaviour is not consistent across all Windows 11 builds, but it works often enough to be worth trying.

To test:

1. Copy the content from the normal source.
2. Open Win+V (assuming clipboard history is enabled).
3. In the elevated target, click to position the cursor.
4. Open Win+V again and click the item to paste.

If Win+V paste works in the elevated target, this is the fastest workaround. If it does not, fall back to workaround 1 or 2. For more on Win+V, see what Win+V actually opens on Windows 11 and how to enable clipboard history in Windows 11.

Workaround 4 (advanced): UIAccess flag

Windows has a uiAccess attribute that allows a process to bypass UIPI in specific scenarios. The attribute is intended for accessibility tools and on-screen keyboards, and it requires the executable to be signed with a trusted certificate and installed in a trusted location (typically Program Files).

Building a uiAccess=true tool to ferry clipboard across the integrity boundary is technically possible but is overkill for daily use. The signing requirement alone makes it impractical for individual users. The attribute is mentioned here only so that users encountering it in documentation know what it is for.

Microsoft documents UIAccess in the Win32 documentation. For most users, workaround 1 or 2 is sufficient.

What does not work

A few commonly suggested fixes do not work for the UIPI block:

• Restarting the Clipboard User Service. The service is healthy; the block is at the integrity level, not the service.
• Restarting explorer.exe. The shell restart does not change process integrity levels.
• Disabling UAC. Disabling UAC is not recommended and does not actually change integrity levels; it just stops the prompts. The integrity boundary is still enforced.
• Running the target unelevated. Some targets genuinely require elevation (e.g., writing to HKEY_LOCAL_MACHINE in regedit). Running them unelevated changes the workflow and may not be possible.

Common scenarios and which workaround fits

The pattern is that the elevated target almost always has a non-clipboard input method (file open, browse, type) that does not cross the UIPI boundary. Using that method is usually faster than the workarounds above.

Prevention

The cleanest prevention is to avoid elevating apps unnecessarily. Most daily work — browsing, email, document editing — does not require elevation. The fewer elevated windows are open, the fewer UIPI boundaries exist, and the fewer paste failures occur.

For users who must run elevated tools regularly (developers running elevated PowerShell, IT admins running elevated management consoles), the practical answer is to accept the boundary and use the file-bridge workaround (workaround 2) as a habit. A small clip.txt file on the Desktop that gets overwritten on each cross-boundary copy is a low-friction bridge.

A short checklist

If only one thing is checked, it should be confirming the elevation mismatch (Task Manager → Details tab → Integrity Level column). If two, add workaround 1 (elevate both sides). If three, add workaround 2 (file bridge). The block is by design and is not a bug; the workarounds are how Windows expects users to deal with it.

Background for this constraint is Mouse Right-Click Paste Missing.

Related reading

• Ctrl+V Inserts a Letter V
• Mouse Right-Click Paste Missing
• Win+V Not Working on Windows 11: 9 Fixes
• Best Free Clipboard Manager for Windows

Sources

• Microsoft Support — Using the clipboard on Windows — official description of the Win+V feature and how the live clipboard interacts with apps
• Microsoft Learn — User Interface Privilege Isolation — Windows security documentation covering UIPI, the mechanism that blocks clipboard transfer across integrity levels
• Microsoft Learn — Mandatory Integrity Control — Windows security documentation covering integrity levels and how they are assigned to processes
• Microsoft Learn — UIAccess attribute — Win32 documentation covering the UIAccess flag that allows accessibility tools to bypass UIPI
• Microsoft Learn — User Account Control — Windows security documentation covering UAC and how it relates to process integrity levels

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