Click Stop on running terminals in Codex app does not close them out

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #12454

Powered by Codex Action

I opened a draft PR for this stop/no-op behavior: https://github.com/openai/codex/pull/12506

The change makes v1/v2 interrupt APIs return immediately when no turn is in progress by cleaning background terminals in that path, instead of waiting indefinitely for a TurnAborted event.

Also included regression coverage in both app-server interrupt suites.

Given the updated contribution policy (invitation-only PRs), #12506 is a narrow draft patch proposal for the Stop/no-active-turn path.\n\nIf maintainers want this pursued, could someone explicitly invite that PR (or point to a preferred issue/PR to fold into)?

Confirmed on macOS Desktop as the stop/no-op cleanup failure case.

Environment:

• Codex Desktop app on macOS (Codex.app 26.313.41514)
• local sessions on codex-cli 0.115.0

In my case /ps showed 25 background terminals running, mostly short-lived commands like sed -n ..., rg -n ..., and python scripts/plan_lint.py ....

The important part: an OS-level ps check right after did not show those short-lived commands as live processes anymore. So /stop here was not failing to kill still-running work; it was failing to clear already-stale background-terminal state from the UI.

That makes this feel like a combination of two issues:

• stale terminal entries remain in the UI after processes are already dead (#12321)
• explicit Stop does not clean that stale state when the turn is effectively idle / there is no active turn to abort

So if helpful for triage: this repro is a strong stop does not close them out case even when the listed terminals are already gone at OS level.

Still reproducible on the current ChatGPT/Codex macOS app.

Feedback ID: 019f5b5b-5f44-7c80-9456-6c92ced0bb7f

Environment

• ChatGPT/Codex app: 26.707.62119 (build 5211)
• Bundled Codex CLI: 0.144.2
• macOS: 26.5.2 (25F84)

Observed behavior

A Vite development server was started by Codex with:

npm run dev --port 5173

The Background Processes panel still showed the terminal entry, but Stop was disabled. Its tooltip said:

For this task, no running process was found.

However, diagnostics taken immediately afterward confirmed that the server was genuinely still running:

• npm process: PID 82464
• Vite/Node child: PID 82485
• listener: 127.0.0.1:5173
• an HTTP request to http://127.0.0.1:5173 returned HTTP/1.1 200 OK
• the npm process was still parented by the Codex app-server
• the process working directory was the affected local project

This is therefore not only stale UI state. The app lost its association with a live background process and could no longer terminate it, leaving the port occupied.

Expected behavior

The Stop action should terminate the complete process group/tree associated with the background terminal and release port 5173.

This workflow worked correctly a few weeks ago, so this appears to be a regression in the current app/runtime.

Potentially related: #25772