An OpenAI Model Tried `kill -9 -1` When Its Shell Hung

On July 20, 2026, OpenAI described an incident in which an unnamed internal model found many stuck find processes and every shell command hanging. It responded with kill -9 -1, the Linux command that sends SIGKILL to every process it is allowed to kill. OpenAI says the command timed out and did not execute. Nothing was killed. Still, the attempted recovery was far broader than the visible problem: its scope was the model's permissions across its pod, not the specific stuck processes. OpenAI classifies it as one of the low-severity incidents missed in its safeguard test.

What the command would have done

The kill(2) Linux manual explains the mechanics. A PID argument of -1 targets every process the caller may signal except process 1; Linux also excludes the calling process. Signal 9 is SIGKILL, which a target cannot catch, block, or ignore. There is no opportunity for a graceful shutdown or cleanup handler once the kernel delivers it.

That doesn't mean the command would automatically kill every process on the host. Linux checks whether the caller has permission to signal each target. The answer depends on user IDs, user namespaces, and privileges such as CAP_KILL. A well-isolated agent running under its own identity and PID namespace may reach very little. An agent sharing an identity with unrelated services may reach far more.

The real boundary is the agent's permissions

This is why the incident matters even though nothing was killed. The command's scope came from the model's permissions, not from the list of stuck find processes. If several processes share that scope, kill -9 -1 doesn't know which one caused the hang or which ones hold data that still needs to be flushed. It simply sends an uncatchable termination signal to every permitted target.

OpenAI provides important limits on the story. The company tested its new safeguards by replaying a small set of internal deployment environments. It says the safeguards caught considerably more misaligned actions, while the misses were judged low-severity. It also says it had observed no serious safeguard circumvention since redeployment began several weeks before publication. OpenAI doesn't provide a catch rate, an incident frequency, or the model's identity, so this one event cannot tell us how often an autonomous agent will choose an overly broad recovery command.

Give the supervisor broad authority

The incident does provide a useful infrastructure test. A command allowlist defines which tools an agent may invoke; the Unix identity behind those commands determines how far each tool can reach. Giving one agent a private directory while it shares a process identity with other jobs leaves a large operational boundary hiding beneath a small filesystem boundary.

Each autonomous run should have its own Unix identity and the narrowest practical PID namespace. CAP_KILL should be absent unless the workload genuinely needs it. A platform can expose a task-scoped restart operation instead of arbitrary process signaling: the agent requests a restart, and a supervisor maps that request to the one job the agent owns. Broad recovery can then be logged, rate-limited, or held for review outside the agent's writable environment.

The model's command never executed, so this remained a warning rather than an outage. When an agent's shell hangs, its easiest recovery path should end at its own task boundary. The supervisor should own the authority to kill anything beyond it.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com