Bug: Opening an MCP-related local history thread corrupts/pollutes other conversations and leaves UI stuck waiting for approval

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

Bug: Opening an MCP-related local history thread corrupts/pollutes other conversations and leaves UI stuck waiting for approval

Reporter

stBlackCat

Product / Version

  • Product: Codex Desktop on Windows
  • Codex CLI: codex-cli 0.130.0
  • Codex Desktop package observed in local logs: OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
  • Runtime line observed in logs: platform=win32 release=26.513.31313

Privacy / Redaction

I am intentionally not attaching raw rollout JSONL or full log files because they contain private local conversation history. The details below are redacted:

  • Windows username replaced with <USER>
  • Local workspace paths replaced with <WORKSPACE>
  • Codex home paths replaced with <CODEX_HOME>
  • Full conversation IDs, request IDs, and rollout filenames omitted or shortened
  • Private conversation content omitted
  • The exact non-English thread title omitted to avoid encoding issues and accidental disclosure

I can provide targeted redacted snippets if maintainers specify exactly which fields are needed.

Summary

Opening one specific local history thread related to adding a Chinese/local model MCP causes Codex Desktop history state to become polluted/corrupted across other historical conversations.

The affected thread title is roughly: add Chinese/local model MCP.

The UI currently gets stuck in a "waiting for approval" state with an infinite spinner. Once I click/open that thread, other historical sessions become polluted as well, so the issue is not isolated to one broken thread.

This looks like a persisted local history/thread state integrity issue, potentially involving MCP/plugin/approval state leaking between conversations.

Steps to Reproduce

  1. On Windows, open Codex Desktop.
  2. Open the local history/recent conversations list.
  3. Click the history thread titled roughly add Chinese/local model MCP.
  4. Observe that the selected thread remains stuck waiting for approval and spinning.
  5. Open or inspect other historical conversations.
  6. Observe that other histories appear polluted/corrupted after the problematic thread is opened.

Expected Behavior

  • Opening one historical conversation should only load that selected conversation.
  • Approval state should be scoped to the selected conversation and should not leak into other threads.
  • Other history entries should remain unchanged and should not receive content, metadata, instructions, approval state, or rendering state from the selected MCP-related thread.
  • If a persisted thread contains malformed or incompatible content, Codex Desktop should isolate that failure to that one thread and show a recoverable error.

Actual Behavior

  • The selected MCP-related thread is stuck waiting for approval and keeps spinning.
  • Opening that thread appears to pollute/corrupt other historical conversations.
  • Local logs show conversation/turn events arriving for conversations the desktop client says are unknown.
  • Local logs also show a local conversation page rendering error shortly after opening/resuming a thread.

Impact

  • High impact: persisted local conversation history integrity is affected.
  • The issue may spread beyond a single corrupted conversation when the user clicks the problematic history entry.
  • Users may need to avoid opening a specific local thread to prevent polluting additional history.
  • The failure mode risks exposing or mixing unrelated historical context between conversations.

Redacted Local Evidence

Recent local session activity was under:

<CODEX_HOME>\sessions\2026\05\17\rollout-*.jsonl

Recent desktop logs were under:

<LOCALAPPDATA>\Codex\Logs\2026\05\16\codex-desktop-*.log

Feature flags around the affected window included MCP/plugin-related features:

Features enabled enabledFeatures="..., apps, plugins, tool_search, tool_suggest, tool_call_mcp_elicitation"

The same window repeatedly performed history/thread operations:

method=thread/list
method=thread/read
method=thread/resume
method=turn/start
method=mcpServerStatus/list
method=plugin/list

The logs also show unsupported feature enablement failures:

unsupported feature enablement `auth_elicitation`: currently supported features are apps, memories, mentions_v2, plugins, remote_control, tool_search, tool_suggest, tool_call_mcp_elicitation

I am not claiming auth_elicitation is the root cause, only that it is visible in the same startup/history load window and may be relevant to feature negotiation or approval/elicitation state.

More importantly, after thread/start / turn/start, the desktop client logged unknown conversation events:

Received turn/started for unknown conversation conversationId=<redacted>
Received turn/completed for unknown conversation conversationId=<redacted>

This occurred more than once around the problematic period.

There was also a React error boundary in the local conversation page:

error boundary
name=LocalConversationPage
errorMessage="invalid syntax at line 1 col 5:

1  cwd=\"<WORKSPACE>\"
       ^"

The stack included local conversation rendering modules such as:

local-conversation-thread-*.js
local-conversation-page-*.js
review-file-source-tab-*.js
app-main-*.js

This looks suspicious because cwd="..." is conversation/session metadata, but it appears to be reaching a parser or renderer that expects a different syntax.

Suspected Area

The likely area is local history/thread loading and event routing in Codex Desktop, possibly interacting with MCP/plugin approval or elicitation state.

The observed behavior suggests at least one of:

  • A selected persisted thread can emit or replay events under a different conversation ID than the desktop client has registered.
  • Approval/elicitation state is not scoped strongly enough to one conversation.
  • Conversation metadata or tool/session context is being rendered or parsed as normal thread content.
  • A malformed persisted event from one thread can poison shared local conversation state used by other history entries.

Request

Please treat this as a local history data integrity bug. At minimum, Codex Desktop should isolate a bad persisted thread so opening it cannot mutate, pollute, or break other historical conversations.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

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

  • #23028
  • #22969
  • #23035

Powered by Codex Action

stBlackCat · 3 months ago

I can reproduce a very similar issue on ChatGPT/Codex Desktop for Windows.

Observed behavior:

  • Creating new Codex tasks works normally.
  • Most existing historical tasks can be opened after restarting the app.
  • One specific historical task crashes the detail pane with “糟糕,出错了”.
  • After opening that broken task, switching to other historical tasks also fails in the same session.
  • Restarting/refreshing the app recovers other tasks, but the same broken task still crashes when opened.
  • The broken task was previously stuck in a “waiting for approval” state.
  • Switching to automatic review allowed new tasks to continue, but did not recover the broken historical task.

This seems consistent with a bad historical task/thread poisoning later task detail rendering in the desktop app.

stBlackCat · 3 months ago

Correction / clarification:

The waiting for approval badge should not be treated as the root cause or primary trigger.

The clearer reproduction is:

  1. In a local Codex Desktop thread related to Chinese/local model MCP routing, ask Codex to perform a GitHub push / GitHub submission workflow.
  2. During or after that GitHub operation, the current conversation page crashes into the generic Codex error screen: Something went wrong with Check for updates and Retry.
  3. Other conversations may still open normally at first.
  4. After opening the crashed conversation again, other conversations can show the same generic error page until Retry is clicked or a new window is opened.

So the important suspected trigger is the GitHub workflow executed from that conversation, not the approval badge itself. The approval state may be incidental UI state from the same thread and should not be over-weighted when triaging the bug.

The previous log evidence is still relevant: repeated LocalConversationPage error boundaries show cwd="<WORKSPACE>" being parsed as invalid syntax, which suggests renderer/navigation state or conversation content handling is being poisoned after the GitHub workflow.

shleder · 11 days ago

This is a strong persisted history-integrity case. I’m field-testing codex-rescue==0.1.0a4 against threads where approval/tool/MCP state may be malformed or leak during replay.

If you still have an untouched copy of the problematic rollout, could you run:

pipx install codex-rescue==0.1.0a4
codex-rescue doctor --json "/path/to/the-affected-rollout.jsonl"

The pass is read-only and won’t open/mutate other conversations. It can help determine whether the selected thread itself contains malformed/correlatable/unfinished persisted state versus the pollution being entirely in Desktop’s shared runtime.

Please share only sanitized status/findings/counts. Don’t post raw rollouts, databases, prompts, MCP/tool arguments or output, credentials, repository data, session IDs, or private paths.