Canceled Codex task kept running/restarting in background and saturated server CPU

What version of Codex CLI is running?

codex-cli 0.137.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt 5.5 xhigh

What platform is your computer?

Linux 5.15.0-179-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

_No response_

Codex doctor report

What issue are you seeing?

A canceled/interrupted Codex task continued running or restarting in the background and saturated the server CPU.

The task was a heavy Node.js worker launched by Codex during an automated workflow. The command looked like this:

cd dist && STRATEGY_REVIEW_RUN_ID=StrategyAH75-test0 node src/test/worker-stream.js -S StrategyAH75 -I 1d,12h,8h --log true > test0 2>&1

Later, a similar background worker was still running:

330790 rtk proxy sh -lc cd dist && STRATEGY_REVIEW_RUN_ID=StrategyZR00-test5 node src/test/worker-stream.js -S StrategyZR00 -I 1d,12h --log true > test5 2>&1
330791 /usr/bin/sh -lc cd dist && STRATEGY_REVIEW_RUN_ID=StrategyZR00-test5 node src/test/worker-stream.js -S StrategyZR00 -I 1d,12h --log true > test5 2>&1
330798 node src/test/worker-stream.js -S StrategyZR00 -I 1d,12h --log true

The original Codex task had already been canceled/interrupted, but the worker continued consuming CPU. Killing the worker was not enough in all cases, because Codex app-server / proxy processes were still active or were recreated.

Observed Codex app-server/proxy processes:

338889 1 338610 Sl codex app-server --listen unix:///home/<user>/.codex/app-server-control/desktop-ssh-websocket-v0.sock
338991 338988 338991 Ss /bin/sh -c ... codex app-server proxy --sock /home/<user>/.codex/app-server-control/desktop-ssh-websocket-v0.sock
339301 338991 338991 Sl codex app-server proxy --sock /home/<user>/.codex/app-server-control/desktop-ssh-websocket-v0.sock

After killing them, new Codex app-server/proxy processes appeared:

341201 1 340898 Sl codex app-server --listen unix:///home/<user>/.codex/app-server-control/desktop-ssh-websocket-v0.sock
341303 341302 341303 Ss /bin/sh -c ... codex app-server proxy --sock /home/<user>/.codex/app-server-control/desktop-ssh-websocket-v0.sock
341614 341303 341303 Sl codex app-server proxy --sock /home/<user>/.codex/app-server-control/desktop-ssh-websocket-v0.sock

The parent process was:

341302 341248 341248 341248 S sshd: <user>@notty

This suggests that the desktop SSH websocket / Codex app-server proxy session was able to recreate the Codex app-server process after manual termination.

The problematic session id / thread id was:

019e927e-8ad8-7691-a663-6e0f9c3a7eda

A Codex session log also showed that the background command had been created by a previous Codex execution session, not by manual shell history:

~/.codex/sessions/2026/06/04/rollout-2026-06-04T11-43-13-019e9271-d33e-7863-96f8-8d0493dc3ffa.jsonl

The generated test log was incomplete and ended with:

Terminated

There were no expected KPI summary markers, so the worker had been interrupted. Despite that, related background work continued/retried and server CPU remained heavily loaded.

The main problem: after cancellation, Codex did not reliably terminate all background/child processes started by the canceled task, and it was difficult to discover and stop all related processes.

What steps can reproduce the bug?

I do not have a minimal standalone reproduction yet, but the observed sequence was:

Start Codex in desktop SSH websocket / app-server mode on a remote Linux server.
Ask Codex to run a workflow that launches a long-running CPU-heavy command.
The command is launched through a process chain similar to:
rtk proxy sh -lc 'cd dist && STRATEGY_REVIEW_RUN_ID=StrategyAH75-test0 node src/test/worker-stream.js -S StrategyAH75 -I 1d,12h,8h --log true > test0 2>&1'
Interrupt/cancel the Codex task before the worker completes.
Observe that the underlying worker can remain active in the background.
Check processes:
ps -eo pid,ppid,pgid,stat,cmd | grep -E 'codex|worker-stream.js|STRATEGY_REVIEW_RUN_ID|rtk proxy' | grep -v grep
Kill the worker and Codex app-server/proxy processes.
Observe that Codex app-server/proxy processes may reappear through a non-interactive SSH process:
sshd: <user>@notty
CPU remains heavily loaded until all related processes and the parent non-interactive SSH session are manually terminated.

Commands used to diagnose:

ps -eo pid,ppid,pgid,stat,cmd | grep -E 'codex|worker-stream.js|STRATEGY_REVIEW_RUN_ID|rtk proxy' | grep -v grep
pgrep -af 'worker-stream.js|StrategyAH75|StrategyZR00|STRATEGY_REVIEW_RUN_ID'
ps -p <PID> -o pid,ppid,pgid,sid,stat,cmd
pstree -aps <PID>

Manual cleanup required commands like:

pkill -TERM -u "$USER" -f 'worker-stream.js'
pkill -TERM -u "$USER" -f 'STRATEGY_REVIEW_RUN_ID'
pkill -TERM -u "$USER" -f 'rtk proxy'
pkill -TERM -u "$USER" -f 'codex app-server'

and also killing specific Codex app-server/proxy PIDs and the parent sshd: <user>@notty process.

What is the expected behavior?

When a Codex task is canceled/interrupted:

Codex should terminate the full process tree/process group started by that task.
Long-running background commands should not continue silently after cancellation.
Codex should not retry or resume canceled work unless the user explicitly asks for it.
The UI/CLI should clearly show any still-running background tasks after cancellation.
There should be a reliable command or UI action to stop all background work associated with the current Codex session.
Codex should not orphan heavy child processes under PID 1.
If codex app-server or codex app-server proxy restarts, it should not resume canceled task execution.
If the task was launched via desktop SSH websocket / non-interactive SSH, there should be a clean way to terminate that session and all descendants.

Additional information

This is high severity for remote development servers.

A canceled Codex task continuing to run in the background can:

saturate server CPU,
make the server difficult to use,
produce misleading or partial test logs,
continue expensive computation without user visibility,
require manual process-tree cleanup,
and make it hard to trust that canceling a task actually stopped the work.

Suggested improvements:

Track all child PIDs spawned by each Codex task.
On cancel, terminate the full process group/tree, including shell wrappers and proxy-launched commands.
Prevent canceled tasks from being retried automatically in the background.
Add a visible “stop all background tasks for this session” command.
Show still-running background commands after interruption.
Warn before starting long-running/high-CPU background commands.
Ensure app-server/proxy restart does not resume canceled tasks.
Provide a cleanup command for desktop SSH websocket sessions and their descendants.