Your next desktop is sixty pixels away.
Hold the wheel button, drag sideways, and Windows moves to the neighbouring desktop. One 270 KB executable for Windows 10 and 11. No Administrator account, no runtime, no driver, no service.
What it does
Four behaviours, each one a line in a file you own.
threshold_px = 60Drag sideways, change desktop
Hold the button and drag horizontally. Every sixty pixels of travel moves one desktop.
repeat_cooldown_ms = 250Keep going to travel further
Keep dragging in the same direction and it walks across several desktops in one motion, with a short delay between switches so a fast flick does not overshoot.
replay_click_when_no_gesture = trueA click is still a click
Press and release without dragging and the click is passed on intact, so middle click keeps closing browser tabs.
max_vertical_ratio = 1.0Vertical drags are left alone
Drag up or down and nothing happens. The gesture stays out of the way of everything else that button already does.
The file lives at %APPDATA%\mouse-desktop\config.toml and is written with comments on the first run. The trigger button, the distance, the direction and the rest are configurable: the full table is in the README, which is where it changes.
Why it exists
The comfortable way of working left with your admin account.
- Tools evaluated first
- 3
- That met all four requirements
- 0
- Privileges this one needs
- None
Windows already changes virtual desktop with Ctrl+Win+← and Ctrl+Win+→, but that means taking a hand off the mouse. Vendor software such as Logitech Options or Razer Synapse can remap a mouse button to that shortcut, and it is genuinely pleasant to use.
The problem is that every one of those tools needs an Administrator account to install. On a managed corporate laptop there is no such account, so the comfortable way of working disappears along with it.
This utility gives it back, using only what a standard user is allowed to do.
What it will not do
Four things it cannot do, before you find out yourself.
Three of the free tools this project evaluated were rejected for problems their own pages did not mention. This one lists its own.
- Elevated windows ignore it
- While the window in front belongs to a process running as Administrator, the gesture does nothing. Windows deliberately hides input from lower privileged processes, and there is no way around that which does not need the Administrator account this utility exists to avoid.
- The ends do not wrap
- On the first or the last desktop, dragging further does nothing. That is how Ctrl+Win+Arrow behaves too.
- The executable is not signed
- Windows SmartScreen warns the first time it runs, and a managed laptop may refuse to run it from a user writable folder at all. Building it yourself from the repository is the surest way to know what you are running.
- It does not get around your company's policy
- Nothing here bypasses a policy. It only avoids needing rights a standard user does not have. If your machine blocks unsigned executables, this one is blocked too.
Before you download
Find out in a minute whether your laptop will run it at all.
On a managed machine, do this before anything else. It is the cheapest way to find out whether the rest is worth attempting, and it installs nothing.
$dir = "$env:LOCALAPPDATA\Programs\mouse-desktop"
New-Item -ItemType Directory -Force -Path $dir | Out-Null
$csc = "$env:WINDIR\Microsoft.NET\Framework64\v4.0.30319\csc.exe"
if (-not (Test-Path $csc)) { $csc = "$env:WINDIR\Microsoft.NET\Framework\v4.0.30319\csc.exe" }
Set-Content "$dir\probe.cs" 'class P{static void Main(){System.Console.WriteLine("probe ok");}}'
foreach ($i in 1..3) {
& $csc /nologo /target:exe /out:"$dir\probe$i.exe" "$dir\probe.cs"
& "$dir\probe$i.exe"
}Delete probe.cs and probe1.exe to probe3.exe when you are done.
Why this and not a copy of notepad.exe
The probe has to be an unsigned executable that has never been seen before, because that is what this utility is and it is the property application control actually judges.
Copying a system tool is a flagged technique in its own right, blocked by a separate Attack Surface Reduction rule, so it fails on machines that would have run this utility perfectly well. The C# compiler that ships in the box with the .NET Framework builds throwaway probes instead.
It compiles three separate binaries rather than running one of them three times. Each compilation is a different file; a second run of the same one only re-reads a verdict already cached.
Read the outcome as a reliable no and an unreliable yes.
- "Access denied" on any of the three roundsIt will be blocked. Stop here.
- Something on the machine blocks unsigned executables, and this utility is an unsigned executable. A message naming your organisation's policy points at application control. A bare denial with no dialog, where even reading the file fails, points at Attack Surface Reduction.
- Three lines of probe okIt will probably run. This is not a proof.
- The rule that does most of this blocking asks the Defender cloud about a file it has never seen, and when that lookup times out the file goes through anyway. On the machine these instructions were tested against, one probe in fifteen slipped past that way while the release executable was blocked every single time. What settles the question is starting the utility itself.
If it is blocked, there is a message written for your IT department further down, with the hash they will ask for. The troubleshooting table in the README tells the two kinds of block apart first, which is what decides what to ask for.
If it is blocked
Plenty of machines just run it. For the ones that do not, the request is written.
On many managed laptops nothing stops it. The most you are likely to see is Windows asking whether you trust a file you downloaded from the internet, and you say yes. Try it before you assume you need permission for anything.
Do you need a request for IT? Here is one.Everything a security team asks before allowing an unsigned executable, with the hash they will want
- What it is, who wrote it, and where the source lives
- The file name, version, size and SHA-256
- Every path and registry key it touches, all inside your own profile
- The two Win32 calls it makes, and that it makes no network connections
- The Defender rule that blocks it, by id and by name
- The event log query that proves that is the rule doing it
- The exclusion being asked for, and the alternative that needs nothing from them
It asks for one exclusion, not for a policy to be relaxed. If the answer is no, that is a reasonable answer and the utility stays blocked.
Subject: Request to allow an unsigned open-source utility (mouse-desktop)
WHAT IT IS
mouse-desktop, an open-source tray utility that changes Windows virtual desktop
with a mouse gesture. It exists because the vendor mouse software that does the
same thing needs an Administrator account to install.
Source code https://github.com/fpinero/mouse-desktop
Licence MIT
Built by GitHub Actions, in public, from the tagged source
THE FILE
Name mouse-desktop-x64.exe
Version v0.1.0
Size 275,968 bytes
SHA-256 5c92e1f82acc8515134bf0384655dbf5518abdf333c12d2a9d61c7e2d1d550de
WHAT IT NEEDS FROM THE MACHINE
Nothing elevated, and nothing outside my own profile:
- Runs from %LOCALAPPDATA%\Programs\mouse-desktop
- One start-up value under
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
- One configuration file under %APPDATA%\mouse-desktop
No driver, no service, no scheduled task, no machine-wide install.
WHAT IT DOES
It installs a low level mouse hook, SetWindowsHookEx(WH_MOUSE_LL, ...), to see
the trigger button being held. Once the pointer has travelled far enough
horizontally it synthesises Ctrl+Win+Left or Ctrl+Win+Right through SendInput.
Both are documented Win32 calls, and neither requires a privilege.
It makes no network connections. Its only dependency is Microsoft's own Windows
API bindings; there is no HTTP client anywhere in the source tree.
WHY IT IS BLOCKED
The executable is unsigned and too new to have a reputation, which is exactly
what Microsoft Defender Attack Surface Reduction rule
01443614-cd74-433a-b99e-2ecdc07bfc25
"Block executable files from running unless they meet a prevalence, age, or trusted list criterion"
judges. That rule denies reads as well as execution and shows no dialog, so the
symptom looks like a file permission problem and is not one.
You can confirm it from the event log:
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' \
-MaxEvents 50 | Where-Object Id -eq 1121
Event 1121 is a block, 1122 is audit only. The message carries the rule id and
the path.
WHAT I AM ASKING FOR
An Attack Surface Reduction exclusion for this file, by the SHA-256 above. If
application control (AppLocker or App Control for Business) also applies, a hash
rule for the same file.
If you would rather not add an exclusion, the alternative that needs nothing
from you is to submit the file to Microsoft through the Defender Security
Intelligence submission portal, which is the intended route for a reputation
block.On an Arm laptop the file is mouse-desktop-arm64.exe instead. The x64 build also runs there under emulation, so ask for whichever one you actually intend to run.
SHA-2563890093c8543d481f428e5268d4821ac0652188b90ea2ea9965b0c05b45b5f40
What you are running
Two documented Win32 calls, and neither of them needs a privilege.
This installs a global input hook, which is a serious thing to let a program do. Here is exactly what it does with it.
SetWindowsHookEx(WH_MOUSE_LL, ...)Watches for the trigger button being held, and hides that button from other applications while it is down, so a drag cannot also open a context menu or start an autoscroll. Release it without dragging and a real click is injected at the pointer, which is what keeps ordinary clicking working.
SendInput(...)Synthesises Ctrl+Win+← or Ctrl+Win+→ once the pointer has travelled far enough horizontally. The same shortcut you could press yourself.
What it deliberately does not use
Windows exposes IVirtualDesktopManagerInternal, a COM interface that changes desktops directly and would be a few milliseconds faster. Microsoft changes its GUIDs with nearly every major Windows update, which silently breaks callers several times a year. Synthesising the documented shortcut survives those updates.
The executable is not signed
That is why SmartScreen warns on first run, and why a managed laptop may refuse it. There is no way to make that go away from a standard user account. Building it yourself is the one answer that does not ask you to trust anybody.
git clone https://github.com/fpinero/mouse-desktop
cd mouse-desktop
cargo build --releaseNeeds Rust on the machine you build on, not on the machine that runs it. The result is one 270 KB file with no dependencies beyond the DLLs that ship with Windows.
Get it
One file. Copy it anywhere and run it.
Download it, or build it yourself from the source, which is the option that lets you know exactly what you are running. Both the utility and this page are MIT.
The Arm build is only needed on an Arm laptop, and even there the x64 build runs under emulation. Downloads come straight from GitHub Releases, never from this domain, so every install counts towards the one reputation that matters.
Or with Scoop, if you already have it
Scoop exists to install software without an Administrator account, which is the exact constraint this was written for. If it is already on your machine, this is the shorter route, and it keeps the utility up to date with the rest of your tools.
scoop bucket add fpinero https://github.com/fpinero/scoop-bucket
scoop install mouse-desktopScoop does not register it to start with Windows. Tick that yourself from the tray icon once it is running.
Release v0.1.0published 23 August 2026
- mouse-desktop-x64.exe275,968 bytes
- SHA-256
5c92e1f82acc8515134bf0384655dbf5518abdf333c12d2a9d61c7e2d1d550de - mouse-desktop-arm64.exe267,776 bytes
- SHA-256
3890093c8543d481f428e5268d4821ac0652188b90ea2ea9965b0c05b45b5f40
Check what you downloaded before you run it: Get-FileHash .\mouse-desktop-x64.exe -Algorithm SHA256