Your phone has capabilities that no menu setting can reach, and an AI agent can unlock them in seconds. Daniel wrote in about something he's been doing that sounds like a power-user secret handshake — pairing Android Debug Bridge, the twenty-year-old ADB toolkit, with Claude Code, the agentic coding tool Anthropic released last year. He's using them together to strip bloatware, fix misbehaving apps, and run maintenance operations that the settings app simply doesn't expose. His bigger point — and I think he's onto something — is that agentic AI isn't a replacement for human skill. It's a force multiplier that lowers the barrier to things you already wanted to do but couldn't, and then actually teaches you the skill along the way.
And it's one of those combinations that feels obvious in retrospect but nobody was talking about. ADB gives you raw shell access to Android's package manager, activity manager, and system diagnostics. Claude Code can take a natural language request — "disable all the Samsung apps I never use" — translate it into the exact shell commands, execute them, check the results, and hand you a rollback plan. All without you memorizing a single flag.
So what exactly are we talking about when we say ADB and Claude Code together? Let's define both concretely before we get into the workflow.
ADB — Android Debug Bridge — is a client-server tool that ships with the Android SDK. It's been around since the platform's earliest days, originally built so developers could debug apps on emulators and physical devices. It lets a computer send shell commands to an Android device over USB or Wi-Fi. Most people who've heard of it know it for sideloading apps or as a prerequisite for rooting. Far fewer know it for system-level package management through the PM tool, or for activity management, or for pulling diagnostic dumps. But that's where the real everyday value lives.
And Claude Code — this is the other half of the equation. Anthropic released it in early twenty twenty-five as a terminal-based agentic coding tool. It's not a chatbot in a browser window. It reads your filesystem, runs shell commands, edits code, and chains multi-step operations autonomously. You give it a goal, it figures out the steps, executes them, and reports back. It's an agent that acts, not a text predictor that suggests.
The key insight is the pairing. ADB gives you raw access to Android's internals — the package manager, the activity manager, content providers, the logcat crash buffer. Claude Code can interpret what you actually want, translate that into ADB shell commands, run them, and verify the outcome. The user stays in the decision loop — you decide what stays and what goes — but the agent handles every bit of syntax, every flag, every verification step. That's the force multiplier Daniel's talking about.
And the reason a non-developer should care is straightforward. Your phone ships with apps you can't uninstall through the launcher. Some of them run in the background, drain battery, eat RAM. The settings app won't let you touch them. ADB will, and you don't need root.
Right — and what makes Claude Code different from just Googling ADB commands is context and safety. If you search "how to remove Samsung bloatware," you'll find a forum post from twenty twenty-one listing package names for a different phone model running a different Android version. You copy-paste those commands and hope nothing breaks. Claude Code can query your actual device, dump the real package list, cross-reference what's safe to disable, batch the operations, and verify each one. It's the difference between following a recipe written for someone else's kitchen and having a chef who's actually looking in your fridge.
Let's get concrete. Here's exactly how the bloatware removal workflow works, step by step.
Step one — you enable Developer Options on your Android phone. Tap the build number seven times in About Phone. Everyone's done this at some point, or at least heard about it. Inside Developer Options, you toggle USB Debugging on. Step two — connect the phone to a computer with Claude Code installed. Step three — you open Claude Code in the terminal and say something like, "List all the packages installed on my Android device and identify which ones are bloatware I might want to disable."
And Claude Code takes it from there?
It runs ADB shell PM list packages, which dumps every installed package name on the device — system apps, user apps, everything. On a typical Samsung phone that's four or five hundred packages. Claude Code parses that list, groups them by likely category — Samsung-specific, Google apps, carrier bloat, third-party pre-installs — and presents you with candidates. You say "disable these twelve." Claude Code generates ADB shell PM disable-user dash dash user zero followed by each package name, executes them one by one, and then runs PM list packages dash dash disabled to verify. The whole thing takes under ninety seconds.
And the dash dash user zero flag — what's that doing?
Android supports multiple user profiles. User zero is the primary profile — the one you actually use. The PM disable-user command with that flag disables the package for your profile only. The APK stays on the system partition, untouched. If something breaks, you re-enable it with PM enable and you're back to normal. That's the crucial safety distinction versus PM uninstall, which can actually break over-the-air updates on some OEMs because the system partition no longer matches what the update expects.
So disable-user is the reversible move, and uninstall is the one that can paint you into a corner.
And this is where the agent adds real safety value. The average user reading a forum post doesn't know that distinction. Claude Code can be instructed — "never use PM uninstall, only disable-user" — and it will enforce that constraint across every operation. It can also check package name databases to distinguish safe-to-remove bloat from system-critical services. Disabling Android System WebView, for instance, breaks every app that embeds web content. That includes a lot of apps you wouldn't expect. Claude Code can flag that dependency before executing.
So the agent isn't just a faster typist. It's bringing knowledge about the ecosystem that a first-time user wouldn't have.
And that's the whole thesis. The user supplies the judgment — "I don't want Facebook on my phone" — and the agent supplies the domain knowledge about how to remove it safely. Neither replaces the other.
What about beyond bloatware? Daniel mentioned fixing things on his phone. What does that look like?
Here's a common scenario. An app crashes every time you launch it. The typical fix is to go into Settings, find the app, clear cache, clear data, maybe uninstall and reinstall. If that doesn't work, people factory reset their phone — which is the nuclear option. With ADB and Claude Code, you can diagnose and fix it surgically. Claude Code runs ADB logcat dash B crash to pull the crash log, analyzes the stack trace, and tells you what's actually failing. Corrupted cache? ADB shell PM clear the package name wipes the app data. A stuck process? ADB shell AM force-stop the package kills it, then ADB shell AM start dash N the activity restarts it with clean state.
So instead of "turn it off and on again" at the device level, you're doing it at the app process level.
And you're getting a diagnosis, not just a blind reset. The crash log might reveal that the app is failing because a content provider it depends on has bad data. Claude Code can then clear that specific provider's data rather than nuking the whole app. It's the difference between a mechanic who says "let's replace the engine" and one who says "your fuel injector is clogged."
I assume all of this works on unrooted devices — that seems like the detail that makes it accessible.
That's the misconception we should tackle head-on. The widespread belief is that you need root access to remove bloatware or do any serious system maintenance on Android. You don't. PM disable-user works on stock, unrooted devices. The app vanishes from your launcher, stops running, stops consuming background resources, and frees up RAM. You can't delete the APK from the system partition without root, but disabling achieves the same practical result for the user. Root is not required for probably ninety percent of useful ADB operations.
And the other ten percent — what are you actually giving up?
Full system app deletion, modifying system-level configuration files, accessing certain protected directories. Honestly, for maintenance and bloatware removal, you don't need any of that. The non-rooted ADB surface is remarkably capable on its own.
Let's put some numbers on this. You mentioned RAM reclamation earlier.
On a three-year-old phone with four gigabytes of RAM, disabling fifteen pre-installed apps can reclaim five hundred megabytes to a full gigabyte of usable memory. These are apps that launch at boot, register background services, poll for notifications — Facebook alone is notorious for this, even if you've never opened it. On a device with constrained memory, reclaiming that much RAM is the difference between apps reloading every time you switch and a phone that still feels responsive.
So we're talking about extending the usable life of hardware that would otherwise feel obsolete.
That's the practical implication. People replace phones because they get slow, and they get slow partly because of resource pressure from software they never asked for and can't remove through normal means. ADB plus an agent makes that fix accessible to someone who has never opened a terminal before. You don't need to know what PM disable-user means. You just need to know you want Facebook gone.
That's the mechanics. But the bigger story here is what this combination says about the role of AI agents in our daily tech lives.
And this is where Daniel's framing is exactly right. Agentic AI is misunderstood as a displacer for human talent. The fear narrative is "AI will replace developers, writers, analysts." But what's actually happening here is different. The user still decides what to remove. The user still reviews the command list before execution. The user's judgment is the irreplaceable part. What the agent replaces is the friction — the arcane syntax, the need to memorize flags, the fear of typing the wrong package name and breaking something. It's automation enabling humans to do what they already wanted to do but couldn't because the barrier was too high.
It's the difference between having a goal and having the means. Most people have the goal — "I want this garbage off my phone." They lack the means because the means require learning a command-line tool designed for developers. The agent bridges that gap.
And here's the knock-on effect that I think is even more interesting. Using ADB through an agent creates a feedback loop that teaches you the tool. You see the commands Claude Code runs. You start recognizing patterns — PM list packages, PM disable-user, PM clear. After a few sessions, you find yourself typing ADB shell PM disable-user from memory. The agent becomes a teaching tool, not a crutch.
So the incentive flips. Instead of the agent disincentivizing you from learning, it actually lowers the cost of learning enough that you start picking it up naturally.
That's the capability enabler thesis in practice. Daniel said it in his prompt — once you see how useful ADB is, there's a strong incentive to learn it to be a better guide to the agent. You're not learning syntax for its own sake. You're learning it because you've seen what it can do, and you want to give the agent better instructions next time. That's a fundamentally different learning dynamic than "read the manual first, then try things."
It's learning by watching someone competent do the thing, then gradually taking over the parts you understand. Apprenticeship, basically.
And that's a model that scales across domains. The same dynamic applies to Claude Code with Git, with database queries, with system administration. The agent demonstrates competence, you absorb patterns, and over time you need the agent less for the routine stuff and more for the genuinely hard problems.
So what does this do to the calculus of buying a cheap Android phone with lots of bloat?
It changes it completely. Budget Android phones — the two-hundred-dollar Samsungs and Motorolas — often ship with more pre-installed bloat than flagships, because the manufacturers subsidize the hardware cost through software deals. Facebook pays to be pre-installed. Carrier apps pay to be pre-installed. The user gets a cheaper phone but pays in performance and battery life. If you know you can strip all of that in ninety seconds with a single prompt, the value proposition of the budget phone improves dramatically.
You're buying the hardware and opting out of the software subsidy after the fact.
Which, I should add, is perfectly legal and within your rights as the device owner. You bought the phone. The apps are on your storage, using your battery, consuming your data plan. Disabling them is not a terms-of-service violation. It's not a warranty void. It's just using a tool the manufacturer left enabled.
Let's talk about risks, because I think that's what stops a lot of people from trying this. What actually goes wrong if you let an AI agent run ADB commands on your device?
The nightmare scenario people imagine is the agent going rogue and bricking their phone. That's not realistic. ADB commands run at the shell level — you can't overwrite the bootloader or corrupt the system partition without root and an unlocked bootloader. The worst realistic outcome from a bad PM disable-user command is that you disable something important, an app stops working, and you re-enable it. It's reversible in seconds.
So the blast radius is small.
Very small. And you can shrink it further with safety constraints. Tell Claude Code "never uninstall, only disable, and always show me the command list before executing." The agent will comply. It's not going to get creative and decide you really meant uninstall. The risk is lower than blindly copy-pasting commands from a forum, which is what most people do when they try this manually.
Because the forum post might be for a different phone, a different Android version, or might just be wrong. The agent is working with your actual device state.
Right. And the agent can do something a forum post can't — it can check dependencies before disabling. If you tell Claude Code "disable Samsung's browser," it can check whether any other apps declare a dependency on that package and warn you. A manual user following a forum list probably skips that step entirely.
What are some of the other maintenance operations beyond bloatware that this combination unlocks?
Scheduled cache clearing is a big one. ADB shell PM trim-caches with a specific size limit tells the system to free up cache space across all apps. You can wrap that into a weekly maintenance script. Storage inspection — ADB shell DF and DU give you a filesystem-level view of what's consuming space, which is often more detailed than what Android's built-in storage analyzer shows. Force-stopping frozen apps, revoking runtime permissions via ADB shell PM revoke, inspecting battery stats with ADB shell dumpsys batterystats — that last one is particularly useful. You can dump the full battery usage report, have Claude Code parse it, and identify exactly which app is causing drain, down to the wakelock level.
So you go from "my battery is dying faster than it used to" to "this specific app held a partial wakelock for forty-seven minutes yesterday."
And then you can decide whether to disable that app, restrict its background activity, or uninstall it. The data drives the decision.
Is there anything that used to work that no longer works? I know Android's been locking things down over the years.
The big one is ADB backup. Android twelve and later deprecated ADB backup in favor of cloud-based backup solutions. If you try to run it, it'll either fail silently or produce an incomplete backup. Claude Code can warn you about this — "that command is deprecated on your Android version, here's the alternative." That's another place where the agent adds value that a static guide doesn't. A tutorial written in twenty twenty-one will happily tell you to run ADB backup, and you won't know it's deprecated until it fails.
Samsung's also been tightening things on their newer devices, right?
One UI six and later have restricted certain PM commands. Wildcard usage in PM disable-user — where you'd do something like PM disable-user com dot samsung dot star — doesn't work the way it used to on newer Samsung firmware. You have to specify exact package names. Claude Code handles this naturally because it's listing your actual packages and generating exact commands for each one. But it's worth noting because the cat-and-mouse game is real. Manufacturers don't love that users can disable their partner apps.
Which leads to an uncomfortable question. As AI agents make ADB more accessible to normal users, do manufacturers respond by locking ADB down further?
That's the tension. ADB exists because developers need it. But if millions of users start using it through agents to strip carrier bloat, the carriers complain to the manufacturers, and the manufacturers have a choice — accept it or restrict the tooling. Samsung's already shown which direction they lean. The window for this kind of access might not stay open forever.
So the time to learn this is now, while the access is still generous.
I've said before that we're in a golden age for Android diagnostic tools, and I think that's still true, but the edges are fraying. Every Android version tightens something. Every OEM skin adds restrictions. The core ADB functionality is still there, but the friction is slowly increasing. Agentic AI offsets that friction, which is why the combination is so powerful right now.
Let's shift to the practical. If someone's convinced this is worth trying — and I think they should be — what's the exact sequence?
Step one — enable Developer Options. Settings, About Phone, tap Build Number seven times. You'll get a countdown after the third tap. Step two — inside Developer Options, enable USB Debugging. Step three — connect your phone to a computer with Claude Code installed. Step four — open Claude Code in the terminal and say, "List all installed packages on my Android device and identify bloatware candidates." Claude Code will run ADB devices to confirm the connection, then ADB shell PM list packages to dump the package list. It'll present you with categorized candidates.
And step five — review the list and tell Claude which to disable.
You're the decision-maker. Claude Code will generate the disable commands, show them to you, and ask for confirmation. Step six — after execution, ask Claude Code to verify the changes and create a rollback script. It'll run PM list packages dash dash disabled to confirm, and save a script with the corresponding PM enable commands so you can undo everything in one shot.
What safety rules should someone have in mind before they start?
Three rules. One — never let the agent use PM uninstall. Always specify disable-user. It's reversible, uninstall can break OTA updates. Two — always review the command list before execution. Claude Code will show you what it plans to run. Read it. If something looks wrong, ask it to explain. Three — keep a backup of your package list. ADB shell PM list packages redirect to packages dot TXT saves a snapshot of your current state. Claude Code can do this automatically if you ask. If something goes wrong, you know exactly what was there before.
And the rollback script is your undo button.
It's a text file full of PM enable commands. Run it and everything comes back. The whole process is designed to be non-destructive.
The bigger lesson here goes beyond Android. What should someone take away from this about how to think about AI agents?
That agentic AI tools are most powerful when paired with existing infrastructure — ADB, shell, APIs, things that already work and are well-understood. The value isn't in the agent inventing new capabilities. It's in lowering the barrier to entry so more people can benefit from capabilities that already exist. Learn the tool, not just the commands. If you understand what ADB is doing, you can guide the agent more effectively. If you understand what the agent is good at, you can delegate the right things to it.
It's not about replacing expertise. It's about making expertise accessible.
And creating a path to actually acquiring that expertise over time. That's the part I think gets missed in most AI discussions. People talk about AI replacing learning. But used this way, it accelerates learning. You see the commands. You see the patterns. You start doing it yourself.
One last thought before we wrap — because this is moving fast, and the window might not stay open forever.
The open question is whether phone manufacturers will tolerate this at scale. Samsung's already restricting certain PM commands on newer One UI versions. Google has been gradually locking down ADB permissions with each Android release. The cat-and-mouse game between user agency and OEM control is just beginning. Right now, the tools work. In two years, we might be looking back at this as a brief golden window.
Imagine a future where your phone ships with a built-in agent that can negotiate with the OS on your behalf — "disable this bloat, but only if it doesn't break Samsung Pay." We're not there yet, but ADB plus Claude Code is the prototype. It's what that future looks like before it's polished and productized.
And in the meantime, you can do it yourself, today, with tools that are free and already on your computer. Pick one annoying pre-installed app. Connect your phone. Ask Claude Code to disable it. See how it feels to have that power. Then come tell us about it.
The misconception worth busting — and we touched on this — is that you need root access to remove bloatware. PM disable-user works on unrooted devices, achieves the same practical result, and is fully reversible. The app disappears, stops running, and you can bring it back anytime.
And the companion misconception — that agentic AI tools are too risky to trust with device access. The agent executes commands you review. You set the safety constraints. The risk is lower than copy-pasting from a forum, and the results are verified. It's not blind automation. It's guided execution.
Thanks as always to our producer Hilbert Flumingtop. This has been My Weird Prompts. If you try this — and we hope you do — email us at show at my weird prompts dot com and tell us what you disabled. We'll be back soon.
