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 command below. It tells the OS to stop monitoring phantom processes.

Reboot after running it. If signal 9 comes back later, a system update has probably reset the setting, so reapply the same command.

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.

The honest catch for long agent sessions

Disabling the monitor widens the limit; it does not delete the mechanism, and a system update 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. 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 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. 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