›_ Codex Issues
Codex Issues / #34195

Codex Desktop reads MCP App resources before thread/resume when reopening a task

Open 💬 0 comments Opened Jul 19, 2026 by byeval

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

26.715.31925 (build 5551)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 27.0.0 arm64 arm

What issue are you seeing?

When reopening an existing task containing a fullscreen MCP App, Codex Desktop attempts mcpServer/resource/read while the task is still in resumeState=needs_resume. App-server rejects the request with -32600 thread not found.

Desktop briefly paints the previously cached app view, then replaces it with the generic “This view could not be loaded” screen. Clicking “Try again” works because thread/resume has completed by then.

The failed resource read never reaches the MCP server.

This is not specific to one MCP server. A local stdio MCP App (Cowart) also logs the same ordering, but its post-resume resource reload is fast enough that the failure is usually not visible. A remote OAuth MCP App exposes the failure consistently.

Sanitized timeline:

14:52:02.149 thread_stream_view_activity_changed
             resumeState=needs_resume

14:52:02.273 mcpServer/resource/read -> errorCode=-32600

14:52:02.313 Request failed:
             thread not found: <thread-id>

14:52:02.314 Failed to read MCP resource:
             uri=ui://widget/flare/codex-editor.v18.html

14:52:02.449 maybe_resume_started

14:52:03.336 thread/resume -> success

14:52:03.420 maybe_resume_success

14:52:12.316 mcpServer/resource/read -> success
             (after clicking Try again)

What steps can reproduce the bug?

  1. Open a task containing a fullscreen MCP App tool result.
  2. Switch to another task so the original thread unloads and enters needs_resume.
  3. Switch back to the original task.
  4. Observe the cached editor flash briefly.
  5. Observe “This view could not be loaded”.
  6. Click “Try again”; the MCP App loads successfully.

The ordering is reproducible with both a remote OAuth MCP App and a local stdio MCP App. The local app often recovers quickly enough to mask the visible error.

Local stdio timeline:

16:00:23.992 resumeState=needs_resume
16:00:24.019 mcpServer/resource/read -> thread not found
16:00:24.129 Failed to read ui://widget/cowart/canvas.html
16:00:24.275 maybe_resume_started
16:00:27.552 maybe_resume_success
16:00:27.955 subsequent resource/read -> success

What is the expected behavior?

Desktop should not read a thread-scoped MCP resource until the thread is resumed and the thread-scoped MCP clients are ready.

Suggested behavior:

  1. Gate MCP resource hydration on successful thread/resume.
  2. Treat -32600 thread not found during needs_resume as transient.
  3. Automatically retry the resource read after maybe_resume_success.
  4. Keep the cached view or loading state visible instead of replacing it with a terminal error during this transition.

Additional information

View original on GitHub ↗