Run Tests From Your Phone (2026)

Yes, you can run tests from your phone in 2026 — the reliable way is to run the suite in a cloud Ubuntu workspace you reach from a native app, not on the phone's own CPU. The commands are the same ones you type on a laptop: pytest -q, npm test, go test ./.... What changes on a phone is not the syntax, it is whether the run survives. On a local Android terminal the OS kills long runs when you lock the screen; on iSH the Node runners will not even start. Move the run server-side and both problems disappear, because there is no phone process for Android to reap and no emulator in the way. This guide covers where each phone setup breaks and the exact steps to run a suite that finishes.

The blocker isn't the keyboard, it's the kill

People assume the hard part of running tests from a phone is typing flags on glass. It isn't — a terminal toolbar with CTRL, ESC, TAB and arrow keys handles that, and most test commands are short. The hard part is that a test suite is exactly the kind of workload a phone's operating system is built to shut down. Suites run for tens of seconds to minutes, they spawn worker processes, and you naturally lock the phone while they run. Every one of those is a trigger for Android's background-process limits.

This is the honest thing desktop-centric blogs miss: on a laptop a test run is unremarkable, so nobody writes about it. On a phone the run is the interesting part, because finishing it is not guaranteed. We think running tests from a phone is genuinely useful — you can kick off the suite from the train, lock the phone, and read the result when you get off — but only if the run outlives the screen. That is the whole design problem, and it is why the answer is where the run lives, not how you type.

Where each phone setup breaks

There are four common ways people try to run tests from a phone, and each fails at a different point. We have hit all four; here is the honest map.

Termux: the run dies when you lock the phone

Termux is a real Linux userland on Android and pytest runs fine in it for a few seconds. The problem is Android 12's phantom-process killer, which terminates apps whose child-process count crosses a system-wide limit. A test runner spawning workers is a fast way to cross it, and users report the run ending with [Process completed (signal 9) - press Enter], specifically when the screen is locked, even after turning off child-process restrictions (Termux issue #5050). There is an ADB workaround, but it has an ordering trap on Android 12 — we wrote up the exact sequence in the Termux signal 9 fix. Even applied, it is a mitigation, not a guarantee.

iSH: Node test runners can't even start

iSH runs Alpine Linux on iOS through a user-mode i386 emulator. Modern Node's prebuilt binaries emit instructions that emulator does not implement, so node --version can die with Illegal instruction before you get anywhere near a test (iSH issue #2335, open since January 2024). Jest and Vitest are Node programs, so they inherit the crash. It is not a package-source problem, so swapping registries does not rescue it. iSH stays a decent pocket shell for editing and ssh; it is just not a JavaScript test host, as our Node.js on your phone guide explains.

Run the suite in a cloud workspace

The setup that finishes is a cloud Ubuntu container reached from a native app. The shell runs server-side on Ubuntu 24.04 x86_64, which removes the two hard failures above at once: no phantom killer, because there is no phone process to reap, and no emulator, because it is real x86_64 hardware where prebuilt binaries install normally. Here is the whole loop.

# Inside a Cosyra workspace, reached from the iOS/Android app
git clone https://github.com/you/your-app.git
cd your-app

# Node: install and run with a streaming reporter
npm install
node --test --test-reporter=tap        # or: npx vitest run --reporter=dot

# Python: pytest behaves exactly like it does on a laptop
pip install pytest
pytest -q

Then lock the phone. The run is a process on the container, not on the phone, so the screen turning off is irrelevant. On Pro the container hibernates after 10 minutes of inactivity and resumes with your files intact, so the pattern of "start the suite, put the phone in your pocket, read the result at the office" just works. The honest trade-off: there is no offline mode. In a tunnel with no signal, a local Termux run is the only option, and there the phantom killer is a price you pay. That is a real gap and we are not going to pretend it away.

Reading a failure on a 40-column screen

A run that finishes is only useful if you can read the failure on a phone. So we measured it. We wrote a two-test file, ran it through node's built-in runner three ways on 2026-07-23 (node v22.22.1), and looked at how wide the output gets against a portrait phone's roughly 40-column width.

The result was clear. With the dot reporter the entire run drew as .X — one character per test — and the failure block topped out at 44 columns, so it wraps once and stays readable. The default spec reporter printed the same failure with a full stack trace, and those lines ran 150 to 184 columns wide. The width there comes from the absolute file paths the runtime embeds, so it is a floor you hit on any machine, not something a wider phone fixes. The takeaway for phone testing: pick a streaming reporter. pytest -q, node --test --test-reporter=tap, and vitest run --reporter=dot all stream one short line per test instead of repainting the screen, which is what you want when the "screen" is 40 columns wide on a couch. The node:test reporter docs list the built-in options.

Let an agent run the tests and fix the failure

Because the workspace has Claude Code, Codex CLI, OpenCode, and Gemini CLI installed next to your project, the natural phone move is to hand the whole loop to an agent. You prompt "run the test suite and fix whatever is red," it runs the runner, reads the failing assertion, edits the code, and reruns — all server-side while you watch from the phone. That closes the gap the GitHub mobile app leaves open: the app lets you approve a pull request from a queue at the pharmacy, but it cannot check out the branch, run the failing test, and fix it. Running the tests where an agent can also fix them is the point. The edit-commit-review steps that surround the run are covered in our shipping code from your phone pillar, and the clone-and-push mechanics in git from your phone. And once you push, the same suite runs again in CI — you can watch that GitHub Actions run go green from your phone without opening a laptop.

FAQ