DEV Community

Cover image for Running the full Claude Code CLI on a stock Android phone: no root, no PC
Lin Simon
Lin Simon

Posted on

Running the full Claude Code CLI on a stock Android phone: no root, no PC

Disclosure: I'm the developer, and Keva is a paid app with a 7-day trial.

I wanted the real Claude Code CLI on my phone. Not a remote session, not a cloud desktop: the actual CLI, running locally, working on local files. Here's what that took, how Claude Code itself built most of it, and what I learned along the way.

What I built

Keva runs Claude Code (and OpenAI Codex) on an ordinary Android phone.

  • A full Ubuntu arm64 userland inside the app (Node.js, Python, git), unpacked on first launch. That's most of the 766 MB APK.
  • A ptrace + seccomp supervisor between Android and the CLI, so glibc binaries run on Android's kernel without root.
  • targetSdk 28. On newer targets, Android's SELinux policy blocks executing files from the app's own storage. It's the same wall Termux hit.
  • Direct to the provider. Prompts go straight from the phone to Anthropic with your own API key or Claude subscription. Nothing passes through my servers.

How Claude Code was used

Claude Code (Opus) is the lead engineer on the project:

  • It reads the codebase and writes the spec for every change.
  • It hands implementation to other coding agents, then reviews every diff line by line and re-runs the full test suite itself (3,000+ Flutter tests, ~280 Kotlin tests) instead of trusting the agent's report.
  • A second model does adversarial review rounds. Claude decides which findings are real bugs and which are opinions, and loops until the reviewer says "mergeable".

Last week a user on an unusual Android build hit "tap Send, app vanishes, no logs". Claude diagnosed it from the code alone (an uncaught Throwable on a Kotlinbackground thread kills the whole process), specced the fix plus self-diagnosing crash reports, and shipped it after four review rounds. The user's reply the next morning: "it works now."

What I learned

  • Re-verify every claim an agent makes. Reviews are useful, but a meaningful share of findings don't survive a check against the actual code.
  • Give the reviewer a ship gate up front. "No path worse than the base commit; pre-existing issues get logged, not fixed." Without it, review rounds keep expanding scope.
  • Commit your own work before dispatching agents. They will "clean up" uncommitted changes they didn't make.
  • Test content, not paths. A test that only checked "the file exists" passed while 47 MB of a bundled tool was missing.

Happy to go deep on any of this in the comments, especially the ptrace/seccomp layer, which was the hardest part.

Keva is at keva.chat.

Top comments (0)