›_ Codex Issues
Codex Issues / #32997

Codex desktop app task appears running but is actually stuck; duplicate MCP/app child processes accumulate

Open 💬 8 comments Opened Jul 14, 2026 by lffyd
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

  • ChatGPT desktop app with Codex - Bundled Codex version: codex-cli 0.144.2

What subscription do you have?

ChatGPT Pro version

What platform is your computer?

  • macOS 26.5, arm64, Build 25F71

What issue are you seeing?

Title:
Codex desktop app task appears running but is actually stuck; duplicate MCP/app child processes accumulate

Environment:

  • macOS, arm64
  • ChatGPT desktop app with Codex
  • Bundled Codex version: codex-cli 0.144.2
  • The issue started after the recent merged ChatGPT/Codex desktop app update

Issue:
Codex local tasks sometimes appear to still be running, but no real progress happens. The UI stays on a tool card, and I have to manually stop the task and resend the prompt to continue.

Steps / scenario:

  1. Use a Codex local task inside the ChatGPT desktop app.
  2. Run a task that calls MCP tools.
  3. The UI continues to show the task as running, but the tool call does not return or progress.
  4. Manually stopping and resending the prompt makes it work again.

Expected behavior:
Tool calls should either complete or fail clearly, and the UI state should stay in sync with backend execution. The app-server should not spawn duplicate MCP/app child processes.

Observed evidence:

  • The Codex app-server had an unusually large number of direct child processes.
  • Multiple MCP/app child processes were duplicated.
  • After terminating duplicate child processes, the direct child process count returned to normal and the stuck behavior improved.
  • Codex desktop logs showed:
  • mcpServerStatus/list taking a very long time
  • repeated app/list failures
  • failed to list apps: Failed to parse JSON response
  • AppServerRequestError(-32603)
  • Codex app-server is not available
  • Item not found in turn state

Impact:
Long-running tasks and MCP tool calls become unreliable. The UI looks like the task is still running, but in practice it is stuck and requires manual interruption and retry.

What steps can reproduce the bug?

Feedback ID: 019f5f42-a918-70c2-acec-29b3fb79280f

What is the expected behavior?

Tool calls should either complete or fail clearly, and the UI state should stay in sync with backend execution. The app-server should not spawn duplicate MCP/app child processes.

Additional information

_No response_

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 6 days ago

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

  • #32942
  • #31946

Powered by Codex Action

stealth-Lee · 6 days ago

Hey, how did you solve the problem? Can you please share?

Chen0x2A · 6 days ago

same problem

lffyd · 6 days ago
Hey, how did you solve the problem? Can you please share?

I have identified the cause and manually killed the duplicate processes as a temporary workaround; however, this does not solve the root issue, and the problem keeps recurring. Since the underlying issue lies in how the client manages the app-server process lifecycle, I am reporting it here so that the official team can fix this bug.

stealth-Lee · 6 days ago
> Hey, how did you solve the problem? Can you please share? I have identified the cause and manually killed the duplicate processes as a temporary workaround; however, this does not solve the root issue, and the problem keeps recurring. Since the underlying issue lies in how the client manages the app-server process lifecycle, I am reporting it here so that the official team can fix this bug.

Is there a temporary solution?

lffyd · 6 days ago
> > Hey, how did you solve the problem? Can you please share? > > > I have identified the cause and manually killed the duplicate processes as a temporary workaround; however, this does not solve the root issue, and the problem keeps recurring. Since the underlying issue lies in how the client manages the app-server process lifecycle, I am reporting it here so that the official team can fix this bug. Is there a temporary solution?

You could try letting Codex handle it; that’s what I did. However, Codex only killed the duplicate MCP processes for me—the duplicates kept reappearing, and the tool cards continued to cause lag in the session.

Wenboo333 · 6 days ago

I would like to add my case as a related but slightly different symptom.

In my case, the tool calls usually complete successfully. For example:

  • Files are edited successfully.
  • Shell commands return successfully.
  • Build or screenshot commands may finish normally.

However, after the tool result is returned, the Agent does not continue to the next step. It remains stuck on progress messages such as:

"Confirming to keep Home component"
"Verifying build status..."
"Implementing local count updates..."

The task only resumes after I manually click "Stop" and send another prompt asking Codex to continue from the current progress.

After the additional prompt, Codex can usually continue normally.

So my case seems to be related to the tool-call pipeline/state transition issue, but the difference is that the child process/tool itself is not always hanging. The failure happens after the tool execution completes, when the Agent should process the result and continue the workflow.

Environment:

  • Windows 11
  • Codex Desktop latest version
  • Tested with GPT-5.5 and GPT-5.6
  • Sandbox mode: elevated

This started after the recent Codex update. Before the update, the same project and workflow worked normally.

rwang23 · 4 days ago

Windows corroboration from the merged ChatGPT/Codex desktop app: one enabled stdio MCP configuration entry was repeatedly started by the same codex.exe parent and retained as 13 independent stacks. The sample contained 52 related processes (13 wrapper PowerShell, 13 real PowerShell, 13 Node, and 13 console-host children) using about 1.64 GB working set while a 5-second CPU sample was idle.

This rules out a simple duplicate-config explanation in that environment. Restarting the desktop app cleared the current pool, but the client recreated stacks during the session. Manually killing children is therefore only temporary and risks breaking active tool calls.

For the associated Windows console flashes, I maintain a separate narrow local mitigation:

https://github.com/rwang23/codex-windows-console-guard

It hides matched launcher windows but does not deduplicate or reap MCP servers. The upstream fix likely needs desired-state ownership for each MCP server plus deterministic shutdown/reuse when a task, app-server connection, or session is superseded.