Skip to content

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

Open
Open
Codex desktop app task appears running but is actually stuck; duplicate MCP/app child processes accumulate#32997
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serverstool-callsIssues related to tool calling

Description

@lffyd
lffyd
opened on Jul 14, 2026

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

Activity

  1. lffyd
    added
    appIssues related to the Codex desktop app
    on Jul 14, 2026
  2. github-actions
    added
    bugSomething isn't working
    app-serverIssues involving app server protocol or interfaces
    mcpIssues related to the use of model context protocol (MCP) servers
    tool-callsIssues related to tool calling
    on Jul 14, 2026

  3. github-actions commented on Jul 14, 2026

    @github-actions
    github-actionsbot
    on Jul 14, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. genleman-lee commented on Jul 14, 2026

    @genleman-lee
    genleman-lee
    on Jul 14, 2026

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

  5. Chen0x2A commented on Jul 14, 2026

    @Chen0x2A
    Chen0x2A
    on Jul 14, 2026

    same problem

  6. lffyd commented on Jul 14, 2026

    @lffyd
    lffyd
    on Jul 14, 2026
    Author

    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.

  7. genleman-lee commented on Jul 14, 2026

    @genleman-lee
    genleman-lee
    on Jul 14, 2026

    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?

  8. lffyd commented on Jul 14, 2026

    @lffyd
    lffyd
    on Jul 14, 2026
    Author

    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.

  9. Wenboo333 commented on Jul 14, 2026

    @Wenboo333
    Wenboo333
    on Jul 14, 2026

    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.

  10. rwang23 commented on Jul 16, 2026

    @rwang23
    rwang23
    on Jul 16, 2026

    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.

  11. Daniel-Popov-allwyn commented on Sep 18, 2026

    @Daniel-Popov-allwyn
    Daniel-Popov-allwyn
    on Sep 18, 2026

    Corroborating this on Windows with the exact user-visible error:

    Error submitting message
Codex app-server process is not available

    On September 18, 2026, message submission stopped working while multiple active tasks remained visibly running but made no progress for about 15 minutes. Restarting the Codex app restored operation.

    Environment:

    • Windows 11 Pro 25H2, build 26200.9457, x64
    • Codex app package: 26.915.3509.0
    • Bundled backend: codex-cli 0.155.0-alpha.9

    Expected behavior: if the app-server becomes unavailable, the app should reconnect or restart it automatically, fail affected tasks clearly, and avoid leaving active tasks stuck indefinitely. A normal message submission should not require restarting the entire app.

  12. Wenboo333 commented on Sep 18, 2026

    @Wenboo333
    Wenboo333
    on Sep 18, 2026 via email
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serverstool-callsIssues related to tool calling

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions