Windows 10 & 11 · PowerShell · Claude skill

OneDrive Exorcism

Removing the app is the easy part. Undoing what it did to your folders is where everyone gets stuck — and on some machines the fix silently never reaches the registry at all.

View on GitHub User manual Playbook

If any of these sound familiar

You delete the OneDrive folder and it comes back.

Files saved to “Desktop” land somewhere else.

Your desktop suddenly shows only shared shortcuts.

Explorer refuses to create or rename a folder.

0x800401E5 — No object for moniker.

The fix worked, verified, rebooted — and nothing changed.

Uninstalling OneDrive does not repoint Desktop, Documents, and Pictures. Those are literal paths in the registry, so Windows keeps writing into a OneDrive folder it recreates on demand — with no sync, no client, and no account.

Two traps that make a broken machine look fixed

Trap 1 — the fake registry

Packaged apps can see an overlay, not the machine

A tool running inside a packaged (MSIX/Store) app may see a copy-on-write overlay of machine state. Writes land in a private hive; later reads return that copy. The fix applies, verification passes, the machine is untouched — through reboots.

Not just the registry: in the field, a scheduled-task query returned zero OneDrive tasks while three were live and armed.

Tell: the fix succeeded, verification passed, and nothing changed.

Trap 2 — the cleanup that breaks Explorer

Deleting a built-in folder description breaks New Folder everywhere

Deleting OneDrive's known-folder definition while child definitions still reference it leaves a dangling parent. Explorer walks that graph during file operations, so New Folder and rename break system-wide — desktop, every drive, every dialog.

The new folder appears in the view but never exists on disk, so every file-system test passes while the shell is thoroughly broken.

Run it

With Claude Code

# copy skill/ to ~/.claude/skills/onedrive-exorcism/, then:
/onedrive-exorcism

With plain PowerShell, elevated

# look before you leap - changes nothing
.\skill\scripts\Invoke-OneDriveExorcism.ps1 -InventoryOnly

# do it
.\skill\scripts\Invoke-OneDriveExorcism.ps1

# New Folder / rename broken, OneDrive or not?
.\skill\scripts\Repair-KnownFolderGraph.ps1

Both scripts are idempotent, report PRESENT vs absent for every item, and end in a PASS/FAIL audit.

What you get back

Desktop, Documents, and Pictures pointing at your local profile again — all six registry values, not the usual three
Three Windows policies blocking OneDrive from redirecting or phoning home ever again
Client, autostart entries, scheduled updater tasks, sync roots, and config keys removed
A repaired known-folder graph, so Explorer can create and rename folders
Stale dialog history cleared, so saves stop landing in a folder that no longer exists
A PASS/FAIL audit you can actually trust, taken from outside the container

Read this first

Files with a blue cloud icon are not on your PC. They exist only at onedrive.com. Removing OneDrive does not delete them from the cloud, but it does make them unreachable from this machine. Run -InventoryOnly to count them, and download anything you need before proceeding.

Leave Windows servicing alone — CldFlt, WinSxS, the component store. Deleting them buys nothing and breaks SFC and Windows Update.
Never delete SyncRootManager itself — other cloud providers register there.
The empty folder is cosmetic; the redirection is the bug. Escalating against a harmless leftover is what causes Trap 2.