Meet AI Termux WADB Toolkit: Let Your AI Work With Your Android Phone
Most Android automation workflows still make the owner do the boring part: open a terminal, copy a command, switch back to an AI chat, paste the output, upload a file, wait for the next instruction and repeat.
I wanted a different workflow.
AI Termux WADB Toolkit connects a compatible AI assistant to a real Termux environment on an Android phone. Once the owner completes the initial MCP and Android authorization, the assistant can run commands available in Termux, use installed tools, work with accessible phone files, use the Toolkit's Android-shell options and save results back to the device.
The important point is that the AI is not limited to the Toolkit's own commands. It can use the normal command-line environment that is already available to the connected Termux session. The owner can still run the same commands manually.
This is an independent project, and the first public release is now available.
What problem does it solve?
Think about a project folder on your phone. You want an AI to inspect the source, find a problem, run a test, build the project and save a corrected copy.
Without a direct working connection, the workflow often becomes:
- Find the files on the phone.
- Upload or attach them to the AI chat.
- Explain the project structure.
- Copy suggested commands into Termux.
- Copy terminal output back to the chat.
- Repeat until the task is finished.
- Download or recreate the final result on the phone.
With the Toolkit connected, the AI can work through Termux instead. It can inspect accessible folders, run the tools that are installed, check the output and save the result in the phone's storage that Termux is allowed to access.
The owner still approves the initial connection, Android permissions, pairing codes, root prompts and any system confirmation that Android requires.
The whole working model
The system has several separate layers. They have different responsibilities, and keeping those responsibilities separate is important.
The connection path is:
AI assistant or AI client → Remote MCP connection → Desktop Commander running on the phone → Termux command environment → AI Termux WADB Toolkit and the other programs installed in Termux.
From Termux, the Toolkit can also use two distinct Android shell routes when needed:
- Wireless ADB, using Android's authenticated Wireless Debugging service.
- Secure Local Shell, a separate local authenticated route prepared through an already-authorized Android shell.
WADB Bridge is a small Android companion for the supported Wireless Debugging setting workflow and Android-side recovery integration. It is not the AI client, the MCP server or a general-purpose phone-control app.
Uploading the Toolkit ZIP or an instruction file to an AI chat does not connect the AI to the phone. The actual Remote MCP connection and Android authorization must be completed.
What each layer actually does
1. The AI app
The AI app is where the owner describes the task in normal language. The Toolkit is not tied to a particular model. It relies on an AI client that supports the required Remote MCP or compatible connector integration.
This means it can be used with different AI services when that service makes the necessary tool connection available to the user's account. A free account can benefit too when its provider supports that integration on the free tier. The Toolkit cannot unlock a connector or feature that the AI provider has not made available.
2. Remote MCP and Desktop Commander
MCP is the tool-connection layer. Desktop Commander is the external service that exposes the phone-side command and file tools to the compatible AI client.
Desktop Commander runs on the Android/Termux side. After the owner authorizes the connection, the AI can ask the connected service to execute commands, inspect results and work with files available to the Termux process.
Desktop Commander is installed separately; it is not bundled as an AI model or chat application inside the Toolkit.
3. Termux
Termux provides the actual working environment. It has a shell, a package manager and installed programs such as Python, Git, Android platform tools, compilers, archive utilities and other command-line tools the owner chooses to install.
Once connected, the AI can ask Termux to run any command that is available in that Termux environment and permitted by its current permissions—not just commands created by this Toolkit.
That includes normal shell commands, scripts, Python programs, Git operations, search tools, build systems, archive utilities and Android platform tools when installed. The assistant can inspect output and use the results in the next step.
The Toolkit does not include every possible compiler, parser or reverse-engineering utility. The relevant program must be installed, and the phone must have enough storage and resources for the requested work.
4. AI Termux WADB Toolkit
The Toolkit adds the Android connection-management and reliability layer around the normal Termux environment.
Its main interface is ai-info. A person sees a readable dashboard and guided Control Center. An AI client can read structured status, so it can check the real state before choosing an action.
It brings together Wireless ADB discovery and pairing, WADB Bridge setup, Secure Local Shell management, Desktop Commander process control, optional recovery, notifications, diagnostics, integrity checks and the full command reference.
5. Android
Android still controls permissions, app identity, storage access, background execution and the privilege level of every process. The Toolkit works with those systems; it does not replace them or bypass them.
That distinction is what makes the different routes useful.
The phone becomes a working file location
One of the biggest practical benefits is working with files directly where they already live.
When Termux has been granted access to a shared folder, the connected AI can use the available file tools and Termux programs to:
- browse and search project folders;
- read and edit source files;
- compare versions and create a separate working copy;
- inspect logs, manifests, configuration and build output;
- process supported documents, images, archives and other formats;
- run tests, scripts and builds when the necessary toolchain is installed;
- create reports, archives or generated output;
- save the finished files directly back to an accessible location on the phone.
For example, the owner can ask the assistant to inspect a project in Downloads, identify a build error, make a working copy, run the available tests and save the corrected project in another folder. Or it can inspect an APK project, examine its manifest and resources with installed utilities, compare files and save a report beside the project.
This is useful for source-code projects, APKs, archives, logs, configuration files, documents, spreadsheets, images, audio, video and other formats supported by the installed programs and parsers.
What about AI chat upload limits?
Some AI services limit the number of attachments, file sizes or supported formats available in a chat. A connected assistant can often work with files through Termux instead of sending every file through the chat application's upload button.
That can avoid the normal attachment-upload step for many workflows. The files can stay on the phone while Termux searches, filters, parses, hashes, builds or transforms them. The AI can receive the relevant output rather than needing every file attached separately.
There is an important limit: this does not provide unlimited AI usage, context or tool calls. The AI provider still controls account eligibility for MCP, rate limits, usage limits, context size and tool availability. When file content is returned to the model through MCP, the provider's normal context and usage rules still apply.
So the Toolkit gives the AI another way to work with permitted local files. It does not change a subscription, remove provider restrictions or provide a Google Drive login. Think of it as turning the phone's accessible storage into a local working drive for the connected assistant.
Android permissions, storage and privilege
Android does not give every app unrestricted access to the entire filesystem. It separates app-private storage from shared storage and applies scoped-storage rules. Termux can work with its own application files and with shared folders for which the owner has granted access and completed the Termux storage setup.
The AI therefore sees the files that the connected Termux environment can access. It does not automatically get every other app's private data, protected system files or every folder on every storage volume.
There are also different execution identities:
- Normal Termux commands run with the Termux app's Android permissions.
- Wireless ADB shell commands normally run as Android's shell user, UID 2000.
- Secure Local Shell commands also run as Android's shell user.
- Root commands are possible only on a rooted phone with a working su mechanism, and only when the owner authorizes the request through the installed root manager.
Root is not required. The Toolkit supports rooted and non-rooted phones, but it does not silently turn every route into root. Wireless ADB and Secure Local Shell remain shell-user routes.
Wireless ADB: authenticated Android debugging
Android Wireless Debugging provides an authenticated way for the ADB client to communicate with the phone's Android debugging daemon.
The normal first-time process involves enabling Developer Options and Wireless Debugging, pairing the ADB client with the phone using the Android pairing flow, and then connecting over the network.
The Toolkit makes that process less fragile. It discovers the typed pairing and connection services instead of guessing which network endpoint is which. It tries an existing trusted ADB key first and asks for a current pairing code only when Android actually requires pairing. It also guards the pending pairing step so a second connection attempt does not accidentally replace the session while the owner is holding the code.
After pairing, the saved ADB trust can normally be reused until the owner revokes or forgets it. The Toolkit rediscovers the current connection endpoint rather than assuming the same network address and port will always remain valid.
Wireless ADB is useful for ADB-specific actions and for the initial setup of the Android helper routes. It is still subject to Android's debugging authorization and the shell user's permissions.
WADB Bridge: the Android companion
WADB Bridge is a small Android package included in the Toolkit release.
Its Wireless Debugging component works with Android's protected global setting used by the Wireless Debugging control. The Toolkit requests the supported action through the Bridge and checks the resulting state rather than assuming a change succeeded.
Android protects secure/global settings. The required permission is not something an ordinary app can give itself. The supported setup uses an already-authorized ADB shell and the owner's permission approval.
The Bridge also provides the supported Android-to-Termux recovery handoff and a local notification channel. It has a narrow role: it does not provide root, does not host the AI connection and does not expose a general-purpose remote shell.
Secure Local Shell: a separate Android shell route
Wireless ADB and Secure Local Shell are not the same thing.
Secure Local Shell is initialized through an already-authorized Android shell connection. Once prepared, Termux talks to the Android-side helper over an authenticated local-only connection on the phone.
The helper runs as Android's shell user, not root. The steady-state design is separate from the ADB wire protocol and does not require the normal Wireless Debugging network transport to remain active after setup. The design keeps classic ADB-over-network TCP disabled and does not expose this helper as a listener on the phone's Wi-Fi network.
This is useful when Wireless Debugging is turned off but the AI still needs supported Android shell checks or commands. Android process management, force-stop and device-manufacturer background restrictions can still stop the helper, so it may need to be initialized again.
MCP controls and recovery
The Toolkit also manages the phone-side Desktop Commander process.
It can check whether MCP is running, start it, stop it intentionally, restart it, inspect logs and report duplicate processes. It separates the desired state from the observed process state.
A normal start, stop or restart preserves the saved Desktop Commander authorization. Logging out is a separate operation because it removes that saved authorization and may require authentication again.
Recovery is optional and controlled by the owner:
- Local Termux watchdog: can try to restore MCP when recovery is enabled, the desired state is online and the process is missing. An intentional offline state is respected.
- Android-side Bridge trigger: can request the Toolkit's recovery job after supported Android events and on slower scheduled checks.
- GitHub recovery: provides a separate, narrow control-file path for supported MCP start, stop, restart and status actions. The AI-side writer and phone-side reader can use different GitHub credentials.
Android may delay background work or stop processes. Recovery is not a guarantee that every device will keep every process alive indefinitely.
Notifications and diagnostics
The Toolkit can show local notifications for relevant process and recovery state changes. Termux-side notifications use the Termux:API command package and its compatible Android companion app. WADB Bridge also has its own recovery notification channel.
The ai-info Control Center, structured status and read-only diagnostics help identify which components are available, which connection is ready and what needs attention. The AI can inspect the state before it acts and verify the state afterwards.
The owner can use the same commands manually from Termux. AI is an optional operator, not a requirement.
What can you ask it to do?
A few examples:
“Check the phone's MCP, Termux, Wireless ADB and Bridge status. Tell me what needs attention.”
“Inspect this source-code project, find the build error, fix it and save a separate working copy.”
“Use the commands available in Termux to build this project, run the available tests and explain any errors.”
“Find the files related to this APK, inspect them using the installed tools and save a report beside the project.”
“Use the available Android shell route to check this setting, then verify the result.”
“Restart Desktop Commander without removing its saved authorization.”
“Show me the recovery options before enabling anything.”
The owner describes the task. The AI chooses the relevant Termux command or authorized Android shell route, performs the work it has permission to do and reports what it actually observed.
Why the release is called 1.7.5 HARDENED
1.7.5 is the Toolkit's existing software version. The project already had versioned code and release metadata at 1.7.5 before its first public release. The public release kept that real version instead of renumbering the same code as 1.0 and creating conflicting package metadata.
HARDENED describes the release build's additional integrity and installer protections. These include signed package metadata, independently supplied trust pins, a signed installed-file inventory with permission-mode checks, managed-path preflight, installer locking and rollback snapshots for ordinary caught failures before the installation transaction commits.
HARDENED is a release designation, not a claim that the software is tamper-proof, immutable or independently security-certified. A person controlling the Termux account can still modify their local copy.
Open-source licence: Apache-2.0
The Toolkit is now released under the Apache License 2.0 (Apache-2.0).
This is an OSI-approved open-source licence. It permits people to use, inspect, modify, fork, redistribute and build upon the project, including for commercial use, subject to the licence's terms, attribution, notice and patent provisions.
The full source is published in the repository. The Android Bridge APK is signed by the project's release certificate; forks can build and sign their own versions, but Android package signing identity matters when updating an already-installed app. The private signing key is not included in the repository.
Public release: v1.7.5 HARDENED
The complete source and official release package are available now.
GitHub repository: https://github.com/jaskran0417/ai-termux-wadb-toolkit
Download the v1.7.5 HARDENED package: https://github.com/jaskran0417/ai-termux-wadb-toolkit/releases/download/v1.7.5/AI-Termux-WADB-Toolkit-v1.7.5-HARDENED.zip
Release page, SBOM and checksums: https://github.com/jaskran0417/ai-termux-wadb-toolkit/releases/tag/v1.7.5
The release contains the complete readable Bash, Java and C source, Android Bridge source, installer, AI instructions, architecture and feature documentation, dependency inventory and release verification tools.
The installer verifies the signed package inventory and requires independently published trust values. The GitHub release assets include the CycloneDX SBOM, checksums and trust information.
The Toolkit does not bypass Android permissions, grant unrestricted access to other apps' private data or remove AI-provider account and usage limits. Integrity checks detect changes to covered files; they do not make a user-controlled Termux environment immutable.
Public source, download and release verification
Public GitHub repository: https://github.com/jaskran0417/ai-termux-wadb-toolkit
Official v1.7.5 HARDENED download: https://github.com/jaskran0417/ai-termux-wadb-toolkit/releases/download/v1.7.5/AI-Termux-WADB-Toolkit-v1.7.5-HARDENED.zip
Release page, SBOM and checksums: https://github.com/jaskran0417/ai-termux-wadb-toolkit/releases/tag/v1.7.5
The GitHub repository includes the complete project source. The overview guides explain the system without turning this post into a source-code listing:
- Android architecture: https://github.com/jaskran0417/ai-termux-wadb-toolkit/blob/main/docs/ANDROID_ARCHITECTURE.md
- Features and practical workflows: https://github.com/jaskran0417/ai-termux-wadb-toolkit/blob/main/docs/FEATURES_AND_BENEFITS.md
- Installation and first setup: https://github.com/jaskran0417/ai-termux-wadb-toolkit/blob/main/docs/START_HERE.md
- Open-source licence: https://github.com/jaskran0417/ai-termux-wadb-toolkit/blob/main/LICENSE
The project is now licensed under Apache-2.0. That means people may use, inspect, modify, fork and redistribute the project, including for commercial use, under the licence's conditions. Third-party software keeps its own licence notices.
For first-time release verification, compare the installer and verifier against these values independently of the ZIP:
- Ed25519 release-key SHA-256 fingerprint: 87aaf967095808f2e384ed912a3d28c6e1d969774d4975a905468f26b4078ca5
- Installer SHA-256 (install.sh): bfe24ee317338728f060656a1b3eadc146962d96c9ee3fd715752db451a29cac
- Release verifier SHA-256 (security/verify-release.js): 1b675c9dd8ab97a765cab6344b4edc877788ea873f64772181a03fb5c9b86d56
- Signed package manifest SHA-256: 743ec63e1d75e2e9fd8d5b57bbc7ef745f0bf5bee0be052751566d6ade97321f
- Distribution ZIP SHA-256: 3f4949ab0c4286ae5cea3d20bc10b9715581e15db4f02da26be2ed163a263c08
The release page also contains the CycloneDX SBOM, checksums and independent trust values. Do not trust a fingerprint copied only from the archive being checked.
The point of the project
I don't want another toolkit where the owner has to memorise dozens of commands or keep moving files between the phone and an AI chat just to get work done.
The goal is to connect the AI to the phone, let it understand the environment, let it run available commands, work with accessible files, use the appropriate Android shell route and save results directly on the device—while keeping the owner in control.
The Toolkit is independently developed and is not an official Termux, Android or Desktop Commander product.
Top comments (2)
Good framing as states. After a reboot, which one breaks more often for you: the pairing record itself, or only the session?
One thing that bites a lot of people: the Wireless Debugging port changes on every toggle or reboot, so a script holding the old ip:port fails while pairing is still fine. Re-discovering it with
adb mdns servicesbeforeadb connectavoids a lot of needless re-pairing.(From the Auten team, we drive Android phones over ADB, beta.)
Your concern is Valid these issues was already tackled in the build u can read the new updated post now it have all info