Safety & restore
The tool is built so that a wrong choice costs you a restore, not a factory reset. This page lists every safeguard and its limits.
What it never touches
Live roles
Right before every change, the device is asked which apps currently hold a system role: the home screen (launcher), the keyboard, the dialer, the SMS app, the assistant, WebView, enabled accessibility services and any device owner (for example a work-profile manager). Those apps are skipped, whatever the plan says. Because this is checked live, it follows you if you changed your keyboard or launcher.
The never-touch list
A fixed list of packages is never offered, even if a catalog entry or an overlay names them. It covers the Android framework, System UI, Settings, adb's own shell, Google Play services and the Services Framework, the Play Store, WebView and its libraries, the permission controller and package installer, system data providers (media, contacts, settings, downloads, TV), Wi-Fi, networking and captive-portal components, setup wizards, system update modules, certificates and keychain, input devices (keyboards, remotes, game controllers), storage access and the file picker, plus vendor-critical packages such as Samsung Knox, the Xiaomi updater, Xiaomi Security center (removing it can boot-loop MIUI) and Xiaomi Find Device.
What is never offered at all
- Unknown system apps: reported in the audit, never offered.
- Apps you used in the last 60 days.
- Catalog entries tied to a feature you said you use (for example Chromecast built-in if you use cast).
- Turning Bluetooth off on Android TV or Google TV, because the remote uses it.
- Clearing an app's data. That is a separate command,
clear-data, for one app at a time, only on request, and it asks you to type the package name twice. It cannot be undone and is never part of a plan.
Removal keeps your data
Apps are removed with pm uninstall -k --user <current user>. That removes the app for the current user only; for a preinstalled app the APK stays on the system partition and -k keeps its data. Nothing is deleted from the system image, which is why no root is needed and why restore can bring the app back with cmd package install-existing. Some apps are disabled instead of removed; disabling is undone by re-enabling.
Apps that are not in the system image (ones you or your carrier installed, or a catalog app whose copy came from a store) are different: Android deletes their code when they are removed and keeps only their data. Catalog apps like that are turned off instead of removed. Unused apps you installed are still offered for removal, one by one and unticked; to get one back, reinstall it from its store. Android keeps the removed app's data on the device, which normally lets the reinstalled app pick it up.
Re-checked right before each change
The plan is built from the audit. When you run apply, each item is checked again against the audited state: same device (by fingerprint), same package, still installed, still in the same state, not holding a live role. If anything differs, the item is skipped. apply is a dry run unless you pass --yes.
Health checks and automatic rollback
Higher-risk items, such as turning off the Google app, are applied alone, one at a time. After each one, a health check presses Home, opens your main apps (the ones you named in the interview) and reads the crash log. If the home screen or one of your apps fails, that change is rolled back automatically and the run tells you.
During a run the screen is kept awake so checks can run, and the original screen timeout setting is put back afterwards. A health check needs the screen unlocked: apply wakes the screen and waits up to 90 seconds for you to unlock it, and changes nothing if you don't. If the device locks itself mid-run, the risky items are skipped and apply --yes --resume does them later.
Playback guard
If something is playing, the health check waits instead of pressing Home, so it does not interrupt what you are watching. reboot is refused while something plays (unless you pass --force-while-playing).
Before restarting, reboot waits until Android has saved the run's changes (about 15 seconds after the last one) and restarts through Android's own shutdown, so a restart never undoes the cleanup.
Dropped connections
Wi-Fi connections drop. If the device disappears or a different device answers, apply stops with exit code 5. Reconnect and run apply --yes --resume; it continues where it left off and does not repeat finished items.
Undo: restore, restore.sh and verify
restoreundoes a run's changes newest first: removed preinstalled apps come back withcmd package install-existing, disabled apps are re-enabled, and settings are put back to their recorded value. A setting that was unset before is deleted again, not set to a guessed default. It is a dry run unless you pass--yes; use--item <id>to undo one change.- Every run also writes a
restore.shshell script. It finds the right device by fingerprint and undoes the run with plain adb, so you can recover even without the CLI installed. verifychecks that a run's changes are still in place. System updates (OTA) sometimes re-enable or reinstall apps;verifylists what was reverted.
What cannot be restored
| Change | Why | How to get it back |
|---|---|---|
| Apps you (or your carrier) installed | They have no copy on the system partition, and Android deletes their code when they are removed. | Reinstall from their store (Play Store, Galaxy Store…); their data was kept. This is why they are offered unticked and need their own explicit yes. |
Cleared app data (clear-data) | Data and logins are deleted. | Sign in again. Never part of a plan. |
| Cleared caches | Caches are temporary files. | Apps rebuild them as you use them; logins and settings are kept. |
| A factory-reset device | A reset brings every removed preinstalled app back by itself. The run's record on your computer no longer matches the device, so there is nothing for restore to do. | Nothing to restore; run the tool again if you want. |
Privacy
No telemetry, no account, no network calls of its own. Audits, plans, approvals and reports stay on your computer. Device identifiers are hashed before they are stored. The shareable summary is built from categories and numbers only: no model name, no package names, no list of your own apps. If you use the Claude Code plugin, Claude reads the compact summaries the CLI prints, under your own Claude Code account.
Plugin hooks
The Claude Code plugin ships hooks that block Claude from running raw device-changing commands such as adb shell pm uninstall, adb shell settings put or adb reboot, along with fastboot and root commands. Claude can only change the device through the CLI, so every change goes through the plan, your approvals, the re-checks, the health checks and the restore log. When Claude runs apply --yes, restore --yes, reboot --yes or clear-data, Claude Code's permission dialog asks you first. A second hook stops Claude from editing the tool's own run files. How the plugin works.