Windows Desktop crashes rendering mixed-version MCP tool records (.find on undefined)

Open 💬 1 comment Opened Jul 12, 2026 by 24kchengYe

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

Codex Desktop package: 26.707.3748.0

Bundled/local CLI: codex-cli 0.144.1

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows 11 Home, version 10.0.26200, x64

What issue are you seeing?

Opening some existing local conversations causes the entire conversation page to hit the app error boundary.

The consistent renderer failure is:

Cannot read properties of undefined (reading 'find')

The stack is rooted in the local conversation renderer:

AppRoutes
local-conversation-thread-CO2JBial.js:8:130494
local-conversation-thread-CO2JBial.js:8:123774
local-conversation-thread-CO2JBial.js:8:118274

The failing UI path appears to include mcp-capability-view-frame. The affected conversations contain tool/MCP records produced by different Codex versions, including built-in node_repl MCP calls. Some records do not appear to contain every field expected by the current capability view. The renderer appears to call .find() without first checking that the collection exists.

This is not isolated to one project or one conversation. Multiple recent conversations can trigger the same page crash. Removing two mcp_tool_call_end records from one copied test conversation did not solve the broader problem, because other conversations contain the same or related tool record shapes. The original session files have been preserved.

The same log window also contains conversation-state errors:

Received turn/started for unknown conversation
Received turn/completed for unknown conversation
Conversation state not found

There is also a separate null-field failure in metadata generation:

[ThreadMetadataGenerationService] Failed to generate thread title
TypeError: Cannot read properties of undefined (reading 'id')

Disabling custom MCP servers lowers the amount of MCP data but does not eliminate the failure because built-in tool/MCP records can still be present. This does not appear fixable through config.toml.

What steps can reproduce the bug?

The exact offending field varies across old/new tool records, but the observed reproduction is:

  1. Use Codex Desktop across multiple app/CLI versions and create local conversations that contain built-in or custom MCP/tool calls.
  2. Update to Codex Desktop 26.707.3748.0.
  3. Open an affected existing conversation from the sidebar.
  4. The local conversation renderer attempts to display tool/MCP capability information.
  5. The page reaches the app-wide error boundary with Cannot read properties of undefined (reading 'find').
  6. Navigating to other conversations containing similar tool records can reproduce the same error.

The error was observed in %LOCALAPPDATA%\Codex\Logs\2026\07\12\codex-desktop-...-t0-...log at multiple timestamps in the same app run.

What is the expected behavior?

  • Existing conversations should remain renderable when optional MCP/tool capability fields are absent or use an older schema.
  • mcp-capability-view-frame should validate/normalize its input before calling array methods such as .find().
  • Unknown or newer tool record types should degrade to a generic tool-call view instead of crashing the whole conversation page.
  • Conversation events arriving before local registration should be queued or ignored safely rather than corrupting renderer state.
  • A malformed tool display record should be isolated by a component-level error boundary, not the app-wide route boundary.

Additional information

This may share conversation-state plumbing with:

  • #31090
  • #21167

However, this report adds a reproducible Windows renderer signature specifically involving .find() while rendering MCP/tool capability information across mixed-version conversation records.

I can provide sanitized individual JSONL record shapes and redacted log excerpts if maintainers identify the expected schema. I am not attaching complete conversation files because they contain private project data.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗