HKCU vs HKLM: why “runs without admin” must be a promise about scope

Every Windows “tweaking” tool eventually says it doesn't need administrator rights. That sentence only means something when it translates into a precise technical scope. This post pins down the vocabulary — so when a tool says “no admin,” you know what to audit.

Hives, in one minute

The registry is not one database; it's a set of hives with different owners and different access rules:

Two consequences follow. First, anything that lives in HKCU is by construction confined to the current account — a tool that only writes there cannot break other users or the OS itself. Second, anything in HKLM — services, drivers, machine policies — requires elevation, which is exactly what UAC prompts exist to gate.

Where the elevation line actually is

“No admin needed” is precisely equivalent to: every change the tool makes can be expressed within the current user's writable surface. The moment a feature writes HKLM, creates a service, registers a scheduled task, edits another user's hive, or changes power plans, the promise is gone — the tool will either show UAC, silently skip the step, or worst of all, write partially and leave a broken half-state.

The audit question: not “does it ask for admin on launch,” but “name one setting it changes and point to the hive.”

What fits comfortably in per-user scope

A surprising amount of legitimate tuning is HKCU-only:

• Startup approvals — the per-user Run and StartupApproved\Run keys (see the blob deep-dive).
• Visual feel — menu show delay, window/taskbar animations, drag-full-windows, listview shadows.
• Responsiveness — hung-app and wait-to-kill timeouts, foreground flash count.
• Privacy — advertising ID, tailored experiences, consumer-content policy (per-user policy key), search-box suggestions.
• Cleanup — your own %TEMP%, thumbnail cache, and queued crash reports with age and lock discipline.

What does not fit: services, drivers, machine policies, other users' profiles, power plans, security settings. A per-user tool shouldn't have menu items for these at all.

A two-minute smell test for any tool

1. Does the download page say where it installs? %LOCALAPPDATA%\Programs means per-user. Program Files means admin.
2. Does it claim to tweak services or “system responsiveness” with no UAC? The claim is a contradiction; one of the two halves is false.
3. Check the manifest's trust level. Per-user apps declare requestedExecutionLevel asInvoker. Tools shipping requireAdministrator want elevation on every launch.
4. Run it with a deny-by-default UAC, on a standard account. Every feature that actually works there is proven per-user. Everything greyed, errored or prompt-y wasn't.

Defaults: restore, don't reverse

One last habit separates careful tools from careless ones: how they undo. When you restore a documented Windows default, the correct operation is usually to write the documented default value (e.g. menu delay back to 400) — or, for policy values that didn't exist before, to delete the value entirely so Windows falls back to its built-in behavior. What you never do is “set the opposite.” A privacy setting whose default is absent is restored by removal, not by forcing an explicit 1.

ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.