One Claude Prompt Debloats Android TV Without Breaking It: A Case Study in Agent Constraints

Android TV and Google TV have a well-known disease. The manufacturer ships the device with a pile of first-party apps you never open, recommendation widgets that fill the home screen with suggestions, and background services that burn the little CPU the TV has. The interface gets slower, and the worst part is that most of this cannot be uninstalled through the normal settings screen.

On August 29, 2026, a Turkish developer named Mert Cobanov published a prompt for agentic coding tools like Claude Code, aimed at exactly this problem. The prompt is hosted at tv.cobanov.dev, and in the days since, several users on social media have run it on TCL sets and reported real results: no more preinstalled junk, no more ad widgets, a snappier launcher.

The cleanup is a nice trick. The prompt design behind it is a genuinely good lesson in how to give an agent a powerful task without letting it break your hardware.

What the prompt actually does

You give the prompt two pieces of information: your TV model and its local IP address. The agent then handles the rest over ADB, the Android Debug Bridge, the same protocol developers use to control Android devices from a computer.

Before you run it, you have to flip two settings on the TV itself: enable developer mode by pressing seven times on the Build entry in the system information screen, then enable USB or wireless debugging under developer options. The IP address lives in the network settings. None of this TV-side preparation requires a computer, and none of it is destructive by itself. Running the agent is a different step: that needs Claude Code or Codex plus an adb client on a Windows, macOS, or Linux machine connected to the same network as the TV.

From there, the agent picks a sequence of packages, disables them, and stops to check the result. The package pass is the core of the job, but not all of it: the prompt also slows the system animations, clears caches, installs FLauncher as the new home screen, and reboots the TV at the end. The rules around each step are where the thinking went.

The constraints are the article

Here is where most people would paste a prompt and hope. The value of this one is that it encodes a set of safety rules that look obvious in hindsight and are almost never written down by the average user.

Package changes are locked to one reversible primitive. The prompt forbids uninstalling anything. Every package change goes through pm disable-user, which puts an app to sleep instead of erasing it from the system partition, and every disable is undone with a single pm enable call. The agent also logs every package it touches, with the undo command written down next to it. This is the single most important design decision in the whole project: the riskiest category of change operates on a strict do/undo pair, so a package mistake costs a command, not a factory reset.

The non-package steps each have their own, milder undo path. Animation speeds are changed with settings put and restored by setting the scales back to 1.0. Cache trimming frees space and has nothing to undo; apps simply rebuild caches on later launches. The home-screen swap is sequenced so FLauncher is installed, opened, and set as default before the stock launcher is disabled, and switching back is a settings change. The final reboot is transient. None of this is risk-free at the extreme: the prompt's own do-not-touch list warns that disabling com.android.location.fused can boot-loop the TV on some builds, which no later pm enable can fix from a dead OS, and that is exactly why the list exists. Destructive operations — bootloader unlocking, custom ROM flashing — remain banned outright, which removes the two categories of action that can permanently brick a television.

Work proceeds in small batches with verification gates. The prompt instructs the agent to handle about ten packages at a time, then stop and confirm the remote control, HDMI input switching, sound, and virtual keyboard still work before continuing. That converts a long automated session into a series of short, checkable steps, which matters because a remote that stops working is a problem you notice immediately, and a package name that looks harmless but is load-bearing is not.

Some packages are explicitly off limits. The prompt ships a do-not-touch list: Google Play services, HDMI input management, the keyboard, and the stock home launcher itself (com.google.android.apps.tv.launcherx on the Google TV build the prompt targets). The launcher is the cautionary tale, because disabling it before a replacement is running leaves a black screen that the remote has no way to bring back. The list has one fenced exception: the stock launcher may be disabled only after FLauncher (me.efesser.flauncher, an open-source launcher on the Play Store) is installed, opened once, and set as the default home screen. Writing the critical paths down — and sequencing the one deliberate violation — prevents the exact mistake an agent is most likely to make, which is reading a package name and guessing wrong.

Unknown packages trigger a confirmation stop. The prompt requires the agent to ask before touching anything whose purpose it cannot identify. That rule exists because of a real incident: on Cobanov's own TV, a package called com.tcl.suspension sounded harmless enough to disable, and it took the source-switch button off the remote. The name said one thing. The function said another.

The intended end state is also defined: the stock home screen, cluttered with ads and recommendations, gets replaced by FLauncher — the one permitted takedown of the do-not-touch list, executed only after the replacement is confirmed working. So the agent is not just told what to avoid, it is told what the finished setup should look like, which turns a pile of prohibitions into a project with a target.

The transferable rules

None of this is specific to televisions. The same six rules make almost any agent prompt safer, and most of the damage you hear about in agent mishaps comes from missing one of them.

Narrow the action space to one reversible primitive. If the task allows a single command that moves the system into a state you know how to undo, prefer it over the general-purpose version. Uninstall versus disable is the difference between running a script on your machine and running it on a server with snapshots.

Write the undo path into the prompt. An action without a stated undo is a footgun. When you delegate, ask what the exact reversal is and put it in the instructions.

Force checkpoints. Long uninterrupted runs hide their mistakes until they compound. Batches with explicit verification steps mean each error is caught at the smallest possible cost.

List the do-not-touch set explicitly. If there are objects or paths that break the whole system when changed, name them. Do not rely on the model's background knowledge of what a given package or service does, because package names are famously misleading and background knowledge goes stale.

Fail closed on unknowns. When the agent cannot identify the purpose of a target, it should stop and ask, not proceed on a hunch. The suspension-button incident is a perfect one-line failure mode to quote anytime someone argues this rule is overkill.

Define the target state. Constraints tell the agent what not to do. A described end state tells it what to do when the constraints are satisfied, and it prevents both running wild and stopping halfway.

The honest caveats

This is still a power tool. Results will vary by vendor and OS version, Google TV and Android TV builds differ in what they ship, and a package that is safe to disable on one TCL generation may be load-bearing on another. The prompt's own rules handle most of this by asking before touching anything unrecognized, but the verification step still depends on you actually testing the remote, the HDMI inputs, and the sound after each batch.

And the happy tweets are real but selective: a user who successfully cleans up a TV posts about it, while a user whose source-switch button disappeared is more likely to quietly re-enable things. The reversibility is exactly what makes that a boring anecdote instead of a support ticket.

The deeper point stands: the moment you give an agent a tool that can change your system, the prompt is the safety mechanism. Mert Cobanov's prompt is worth reading for the technique, but the safety design is what you should steal.