OfflineTasks

Routine maintenance on Windows machines runs into the same wall every time: the files that most need cleaning are the ones something is holding open. An uninstaller leaves a folder behind and the folder will not delete. A vendor service is gone from the list but its registration is still there. Run the job during the day and it skips what matters; run it by hand after a reboot and it depends on somebody remembering.

Across a set of machines, that turns into work nobody wants and everybody postpones.

The README opens with the limits rather than the features, which is unusual enough to be worth repeating here:

• No arbitrary command execution. A job is declarative JSON with four permitted actions — delete paths, remove services, delete registry keys, uninstall a product by GUID. Each carries hard guards: no drive-qualified paths, no .., system directories never deletable, critical OS services and protected registry subtrees refused.
• No network. No listener, no client, no remote control channel, no telemetry.
• No stealth. Everything is plain text, every run writes a readable report, and the job is validated and displayed before anything is armed.
• Nothing survives the run. The scheduled task, the one-shot boot entry and the Safe Mode service all remove themselves afterwards.

Each of these removes a capability someone would find useful. They are in the README first because a maintenance tool that can do anything is a maintenance tool nobody should trust with administrator rights.

The default engine schedules the work for the moment right after a normal reboot, before the desktop and third-party software start and before anything can take a lock. It is assembled entirely from Microsoft-signed components — the task scheduler, PowerShell, sc.exe — so there is no custom binary in that path at all.

The second engine exists for the cases the first cannot reach, where a file stays locked even immediately after a normal boot. It writes a one-shot boot entry, comes up in Safe Mode exactly once, runs the job there through a small service, then restores normal boot and removes itself. That service is a compiled Go binary, and saying otherwise would undercut the argument the rest of the tool makes: the source sits in the same repository, releases publish SHA-256 hashes, and the binary carries full version information with no packing.

What made the second engine shippable is the answer to “what if the run goes wrong”. The Safe Mode entry fires once. Whatever follows — a crash, a power cut, a failed job — the next boot is ordinary Windows, because the sticky safe-boot flag is never set on the normal boot entry. A machine cannot be stranded by design. Encrypted system volumes are refused outright unless protection is suspended for exactly that one boot.

Deletion is not deletion by default either. Folders on the same volume are moved to a timestamped quarantine rather than removed, registry keys and service registrations are exported first, and a restore script puts any of it back.

The code is public under the MIT licence, commit history and issues included. That is the point: we would rather be judged on something readable than on a description of it.

The honest state of it: there is no code-signing certificate yet, so a strict antivirus policy may flag the Safe Mode binary. The repository says so plainly, in its own section, rather than waiting for somebody to discover it.