Linux desktop: stopped long-running goal leaves trusted-worker.js at sustained high CPU until app restart

Codex App version

ChatGPT/Codex desktop app package 26.825.51511; bundled codex-cli 0.151.0-alpha.7.2.

Subscription

Not included in this diagnostic report.

Platform

Linux 7.0.0-30-generic x86_64 unknown

Ubuntu 26.04.1 LTS, Intel Core i9-12950HX (24 logical CPUs).

What issue are you seeing?

A long-running goal can leave a Codex trusted-worker.js process consuming CPU continuously after the task is stopped or a goal pause is requested. The stuck worker caused sustained thermal saturation until the entire desktop app was restarted.

Observed process and thermal data before restart:

/usr/lib/chatgpt/resources/cua_node/bin/node .../trusted-worker.js <workspace>
trusted-worker.js: 159.48% CPU average during a 5-second pidstat sample
codex app-server: 96.41% CPU average during the same sample
CPU package: 100.0 C (critical limit 100.0 C)
Fans: approximately 3,000 and 4,000 RPM (maximum)

The worker had been alive for more than four hours and had accumulated CPU usage consistent with roughly 1.5 cores continuously. The app-server was also spending unusually high time in system CPU.

Stopping the current turn did not clean up the worker. A /goal pause request was delivered to the active goal, but after more than 30 seconds the thread remained active and the processes still consumed approximately 1.3 and 0.9 CPU cores. Package temperature remained at 99 C.

After fully quitting and reopening the desktop app, the old worker and app-server processes disappeared. Within about two minutes, CPU package temperature fell from 99 C to 51 C and fan speeds fell to approximately 1,200 and 1,600 RPM. This makes the orphaned/stuck Codex process the clearest trigger in this incident.

No project source, prompt transcript, or session logs are attached because they may contain sensitive repository data.

Steps to reproduce

1. On the Linux desktop app, start a long-running /goal in a local repository.
2. Let the goal run for several hours while it performs repeated local tests and browser-based QA.
3. Stop the active turn, then request /goal pause.
4. Observe that the thread may remain active and trusted-worker.js plus the Codex app-server continue consuming sustained CPU.
5. Fully quit and reopen the app; the runaway processes disappear and CPU usage/temperature immediately return toward idle.

This was observed once with detailed process sampling. I cannot safely reproduce thermal saturation repeatedly on the same hardware.

Expected behavior

Stopping a turn or pausing a goal should promptly cancel or quiesce its local workers. The app should enforce worker lifecycle cleanup and should not leave trusted-worker.js or app-server loops consuming CPU indefinitely. If graceful cancellation cannot complete, the UI should report that the task is still stopping and provide a safe force-stop control.

Additional information

Power profile was balanced. The CPU reached its hardware critical limit, so this is also a device-safety and reliability issue. A watchdog or bounded cancellation timeout for local workers would reduce the impact of future stuck states.

Start with the desktop app's stop-turn and /goal pause handling, then trace the lifecycle of the bundled trusted-worker.js and Codex app-server processes. Reproduce the cancellation scenario if safe, and consider the issue resolved when stopping or pausing promptly quiesces the workers or clearly reports an unsuccessful cancellation with a safe force-stop path.