Bug: Opening an MCP-related local history thread corrupts/pollutes other conversations and leaves UI stuck waiting for approval
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
- On Windows, open Codex Desktop.
- Open the local history/recent conversations list.
- Click the history thread titled roughly
add Chinese/local model MCP. - Observe that the selected thread remains stuck waiting for approval and spinning.
- Open or inspect other historical conversations.
- 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.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗