Fix Termux Process Completed (Signal 9) on Android

If Termux dies with [Process completed (signal 9) - press Enter] in the middle of a job, that is the Android 12+ phantom process killer, not a Termux bug. Android kills background ("phantom") processes once the system-wide count passes 32, or when one uses heavy CPU. The fix depends on your Android version: on Android 14+ flip a Developer Options toggle; on Android 12, 12L, and 13 run one ADB command; on rooted phones use su. We cover all three below, then the honest catch: even fixed, a long AI agent session is the workload most likely to get killed.

This guide was written by the Cosyra team. We hit signal 9 ourselves running a long agent session in Termux on an Android 14 phone, and we cross-checked every command against Termux issue #2366 and the fix steps on Ivon's Blog, verified 2026-06-10.

What signal 9 actually is

Signal 9 is SIGKILL, the signal a process cannot catch or ignore. When the Android OS sends it, the process is gone immediately, and Termux reports the shell child died with [Process completed (signal 9) - press Enter]. So the message is accurate but misleading: nothing in Termux failed. Something outside Termux reached in and killed the process.

On Android 12 and newer, that something is almost always the phantom process killer. Android 12 added a monitor that counts background child processes across the whole system and kills them once the count passes a default of 32, and it also targets processes burning CPU in the background. The Termux README warns about exactly this, and the long-running tracking issue #2366 collects hundreds of reports of the same error.

The fix, by Android version

There is no single command that works everywhere, and that is the source of most of the confusion online. What you can do depends on your Android version. Pick the section that matches your phone.

Android 14 and newer: the Developer Options toggle

This is the easiest path and needs no computer. Turn on Developer Options first: open Settings, go to About phone, and tap Build number seven times. Then open Settings, Developer Options, and enable Disable child process restrictions. Reboot. That toggle is Google's own switch for this behavior, and it is the cleanest fix when your device exposes it.

Android 12, 12L, and 13: ADB from a computer

These versions have no toggle, so you change the setting over ADB. Enable USB debugging (same Developer Options menu), connect the phone to a computer with the platform-tools installed, and run the commands below. The first tells the OS to stop monitoring phantom processes.

On Android 12 you also have to raise the phantom-process ceiling, and the order matters. That ceiling lives in device_config, which Google Play Services re-syncs from the server roughly three to four minutes after the device boots and unlocks. If you set the limit without disabling that sync first, the value is silently reverted while you are still waiting for your build to finish, and signal 9 comes back with no visible cause. Run set_sync_disabled_for_tests persistent before the put, not after.

Reboot after running them. If signal 9 comes back later, the two likely causes are a system update that reset the setting, or a device_config value you set without the sync-disable step above. Reapply the commands in the order shown. This is documented in the Android process behavior notes maintained by a Termux maintainer, phantom, cached and empty processes (verified 2026-07-23).

Rooted devices: run it locally with su

If your phone is rooted you can skip the computer and set the same flag from inside Termux. Run the command, approve the root prompt, and reboot.

If you are on Android 12 and also raising max_phantom_processes with su, the same ordering rule applies: run su -c "/system/bin/device_config set_sync_disabled_for_tests persistent" first, or Play Services will re-sync the value away after your next reboot.

The honest catch for long agent sessions

Disabling the monitor widens the limit; it does not delete the mechanism, and both a system update and a Play Services device_config re-sync can quietly turn it back on. For most uses (an ssh session, a quick script) that is fine. For the workload people increasingly want from a phone terminal, running an AI coding agent for half an hour while they do something else, it is shakier. An agent session is a long-lived, CPU-active process, which is the exact profile the phantom killer was built to target — and so is a test suite spawning workers, which is why running tests from your phone hits the same wall. We have watched a perfectly-configured Android 14 phone still kill a long Claude Code on Termux run when it backgrounded the app to save battery on the train.

The usual advice at this point is to wrap the run in tmux so it detaches instead of dying. That does not help here, because the killer takes the tmux server process too, the same [Process completed (signal 9)] line, one layer down. The fixes on this page are what keep a tmux session alive on Android; the tmux on your phone guide covers the session-level setup itself.

Vendor documentation rarely warns you about this, even when the vendor has gone to the trouble of writing Termux docs at all. Pi is the clearest example: its Termux install is officially supported and lists three limitations honestly, none of which is the phantom process killer that actually ends long agent runs.

The opinion we hold that the local-first crowd will push back on: for an agent you want to keep working while your phone is in your pocket, fighting the OS scheduler is the wrong layer to solve this at. The process should not live on the phone at all. That is the design choice behind Cosyra, and it is worth being upfront that it trades away offline use to get there.

Why a cloud container never throws signal 9

The phantom process killer is an Android feature. It does not exist on desktop Linux, and it does not exist in a cloud Linux container. A Cosyra workspace is a per-user Ubuntu 24.04 x86_64 container on Azure AKS, reached from a native Android or iOS app. Because it is real Linux and not Android, there is no 32-process limit and no SIGKILL from a phantom monitor. A long agent run keeps going while your phone is locked, and when you put the phone down the container hibernates and resumes where it left off rather than dying.

The other practical difference is the ABI. Termux is an aarch64 Android userland, so some prebuilt binaries and native packages do not run without workarounds. That bites hardest in the npm ecosystem, where an addon without an arm64 prebuild has to compile from source, the failure mode we walk through in running Node.js on your phone. A container is x86_64 Ubuntu, so standard Ubuntu tooling installs unmodified. We pre-install Claude Code, Codex CLI, OpenCode, and Gemini CLI so an agent is one command away rather than an install fight. For the fuller comparison of the two approaches, see Cosyra vs Termux, and for the range of ways to get a real Linux userland onto Android, including the proot-distro route that has its own phantom-killer exposure, see Android Linux container options.

Who should fix Termux, and who should move off-device

Fix Termux in place if you want a free, local, offline-capable terminal and your phone exposes the Android 14+ toggle (or you are comfortable with ADB). For short interactive work that is the right tool, and it keeps working with no signal. Stay with it especially if offline matters, because a cloud container needs a connection and Termux does not, which we say plainly in the mobile coding terminal guide.

Move the work off the device if your main use is long-running agent sessions, if you are on Android 12 or 13 with no computer for ADB, or if you are tired of a setting that an OS update can silently reset. At that point the container is not a workaround for signal 9, it is a setup where the error category does not exist.

Frequently asked questions