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.