It is worth being straight about this, because the phrase is used loosely. Context menu entries are defined in the registry, and changing what appears in your menu means changing registry state. ContextCleaner writes registry values. Any tool that claims to customise the context menu without touching the registry is either misdescribing itself or not doing anything.
The meaningful distinction is between you making those edits by hand and a tool making them on your behalf with properties manual editing does not have. Four of those properties matter.
Reversible methods over destructive ones. A hand edit typically deletes a key. ContextCleaner instead marks classic entries hidden with a value the shell honours, adds add-on identifiers to the shell block list rather than unregistering them, and renames New-menu registrations rather than deleting them. In every case the original registration survives, so re-enabling restores the previous state exactly rather than attempting to reconstruct it.
Writing to the location that is actually in effect. The same logical entry can be registered per-user, machine-wide, or under a file-type association. Writing to a parallel location succeeds and changes nothing you can see — a silent no-op that feels like a mystery. ContextCleaner records where each entry was discovered and writes to the origin that governs it, in both hives when a registration exists in both.
A snapshot before the fact. A `.reg` export of the keys involved is written before each apply, and if that export cannot be written the apply does not proceed. The safety step is not advisory. Restoring imports per hive independently, so a restore still succeeds for your user account even if a machine-wide portion is refused.
Refusal at the backend, not just in the interface. The entries File Explorer needs to open folders, drives, and network locations are protected by a check in the layer that performs the write, not by a disabled toggle in the UI. A bulk action cannot route around it. Re-enabling is always permitted — the guardrail only blocks removal — and it is deliberately narrow, covering a small set of critical verbs on container classes so that ordinary third-party entries stay fully removable.
There is also a cleanup detail worth mentioning: earlier approaches to this problem, including manual ones, tend to leave behind empty per-user keys that serve no purpose. ContextCleaner removes those when it finds them, scoped strictly to the per-user class area and only for keys with no values and no subkeys, so nothing meaningful is ever caught by it.