A Developer’s Claude-Debloated TV Turns Near-Misses Into an Agent Permissions Playbook

Mert Cobanov opened the developer options on his four-year-old Android TV, connected Claude over ADB, and told it to debloat the device: disable the software he never used, shorten the animation timings, get rid of the ad-heavy home screen. It worked. He posted the results on X, said the TV now runs smoother than when it was new, and published his entire prompt so anyone could repeat it.

Engadget picked up the story with a headline warning that letting an AI agent loose on a TV “isn’t the best idea,” arguing that AI “is prone to mistakes” and could end up disabling a critical component. That caution is reasonable, but it undersells what actually makes the project worth reading. Cobanov is a Senior AI Engineer at Refik Anadol Studio, where he builds production AI agents with long-term memory and backend infrastructure for a living, and the guide he published at tv.cobanov.dev documents at least three specific moments where the debloat could have bricked his television. Each one is now folded into a protected-package list and a batch-and-verify workflow that exists precisely because something already broke once, on his own TV, before he wrote the guide.

What Cobanov actually told Claude to do

The setup is deliberately low-privilege. Cobanov’s guide asks readers to enable developer options (seven taps on the build number), turn on wireless debugging, and find the TV’s IP address, then hand a roughly 850 to 900 word prompt to Claude Code with the TV model and IP filled in. The prompt is broken into five sections: Setup, TV details, Rules, Execution order, and Final deliverables. Nowhere does it ask for root, and it explicitly forbids Claude from getting it: “Do not suggest or attempt rooting, unlocking the bootloader, or flashing a custom ROM.”

The core rule is that nothing gets uninstalled. Every package Claude touches is put to sleep rather than removed:

adb shell pm disable-user --user 0 com.tcl.suspension

and reversed with the paired command:

adb shell pm enable com.tcl.suspension

pm disable-user is the operative detail. An uninstalled app is gone; a disabled one is dormant and can be switched back on with a single command, so a wrong call costs a re-enable, not a factory reset. On top of that, the prompt caps Claude to disabling at most 10 packages before it has to stop and confirm, in Cobanov’s own words, “does the remote’s ‘Inputs / Source’ button still work, can I switch to HDMI, do Netflix and YouTube still open, do sound and the on-screen keyboard still work.” Only after that checklist passes does the agent move to the next batch. He also swapped Google TV’s ad-heavy home screen for FLauncher, a free, open-source app that just shows a grid of installed apps. The result, in his own account: a smoother television, without root, with every change documented as it happened rather than reconstructed from memory afterward.

Three near-misses the guide exists because of

The protected-package list and the batch-test-rollback loop are not generic caution. They read like a record of specific failures, because the guide documents them in the first person:

• The remote lost its HDMI button. “On my TV, disabling com.tcl.suspension killed the ‘Inputs’ button on the remote and I could no longer switch to HDMI.” That package now sits on the never-disable list, alongside the TV’s Bluetooth remote-control service, its input-method (on-screen keyboard) packages, and Google Play Services.
• A different package sends the TV into a boot loop. The guide flags com.android.location.fused by name: disabling it “sends the TV into a boot loop,” a failure mode with no soft recovery short of a factory reset from the outside.
• Killing the home screen before its replacement is ready produces a black screen with no way back. The guide’s fix is ordering, not caution: install FLauncher and confirm it launches before disabling Google TV’s home screen, “otherwise you get a black screen.”

A fourth, lower-severity risk sits alongside these: disabling the wrong DRM-adjacent component can drop the TV’s Widevine certification from L1 to L3, which silently caps Netflix at standard definition instead of HD. None of these are Claude inventing a new failure mode on its own. They are exactly the kind of mistake an agent with broad, unscoped system access will eventually make, caught here because a human was testing in small batches with a real device instead of trusting the first full run.

Reversibility, not caution, is what actually saved the TV

It’s tempting to read the lesson as “be careful with AI agents.” The more precise lesson, visible in the guide’s own structure, is that the specific shape of the permission boundary is what determined the outcome, not how careful anyone felt in the moment. Three design choices did the real work:

Every operation is reversible by construction. Because pm disable-user never destroys anything, the worst outcome of a wrong call is a paired pm enable away from fixed, and the guide requires documenting every change as it happens rather than trusting memory to reconstruct it later.

Verification happens in small, forced increments. Capping batches at 10 packages means a mistake surfaces after ten changes and one testing pass, not after two hundred changes and a single “did everything still work” check at the very end, by which point isolating the cause is far harder.

Unknown territory gets a stop-and-ask default, not a best guess. The guide names an explicit do-not-touch list (remote services, HDMI input handling, Play Services, the keyboard, location services) rather than leaving Claude to infer from a package name alone which components are safe to touch, which is exactly the kind of inference that produced the boot-loop and dead-HDMI-button incidents in the first place.

Root access, notably, was never on the table. A rooted TV with a misbehaving agent is a much worse story than a TV where the deepest available action is “put an app to sleep.” The absence of root is arguably the single biggest reason this stayed a good weekend project instead of a warranty claim.

Why the TV needed debloating in the first place

None of this would be necessary if TVs didn’t ship this loaded. Engadget reports that global smart TV household ownership is on pace to pass 50 percent by the end of 2026, up from roughly a third of households in 2020, and that Samsung TVs alone ship with close to 20 percent of total storage already consumed by the operating system and its pre-loaded software before a user installs anything.

Some of that software is unremovable streaming apps. A meaningful share of it exists to feed automatic content recognition, the technology built into most smart TV operating systems that captures frame-by-frame screenshots of what’s on screen to build a profile of viewing habits for advertisers. The Center for Digital Democracy’s October 2024 report, “How TV Watches Us: Commercial Surveillance in the Streaming Era,” is blunt about the trade-off: “CTV has become a privacy nightmare for viewers,” said executive director Jeff Chester. “It is now a core asset for the vast system of digital surveillance that shapes most of our online experiences.” Low-margin TV hardware is subsidized in part by that data pipeline, which is a large part of why manufacturers make bloatware difficult to remove through the settings menu in the first place, and why a developer reaching for ADB and an AI agent felt like the more practical option.

The same permission-boundary question, at a different scale

Cobanov’s guide is a consumer-grade version of a question sxz.io has covered repeatedly on the enterprise side. Docker’s own explainer on coding-agent “YOLO mode” makes structurally the same argument about flags like Claude Code’s --dangerously-skip-permissions, Codex CLI’s sandbox-bypass mode, and Gemini CLI’s equivalents: the fix for an overcautious agent isn’t fewer confirmation prompts, it’s an isolated boundary the agent can’t step outside of, whatever it decides to do inside it. A batch-of-10, protected-package, disable-don’t-delete workflow on an Android TV is that same boundary, just implemented with ADB instead of a container runtime.

The contrast matters too. The Carbonato botnet that sxz.io covered in September ran on an entirely unmodified, legitimate open-source AI agent framework, repurposed into a Docker-hijacking botnet’s decision loop by swapping in a different persona file. Nothing about the underlying agent software changed between the benign use and the malicious one. What changed was who held the permission boundary and what they used it for. Cobanov’s guide is what it looks like when the person holding that boundary is disciplined about it: small batches, reversible actions, a named list of things the agent is never allowed to touch, and a default of stopping to ask rather than guessing. Carbonato is what it looks like when nobody is.

Cobanov’s own conclusion, buried in the guide rather than the headline, is the more useful takeaway than “don’t let an AI touch your TV”: if you’re going to let an agent operate on hardware you actually depend on, the question isn’t whether it might make a mistake. It’s whether the system around it is built so that mistake costs you a single reversible command instead of a factory reset.