codex - 💡(How to fix) Fix Codex Desktop hangs when clicking a specific drawing/browser-sidebar thread; thread/read succeeds but thread never resumes [1 participants]

Summary

Codex Desktop on macOS reproducibly hangs when clicking one specific historical drawing/browser-sidebar thread:

• Conversation ID: 019cb8c6-a2f7-75c0-8e2d-8e1d084334c2
• Symptom: clicking the thread makes the whole Codex Desktop app become very sluggish / hang, and the historical content never renders
• Impact: the thread appears to contain active/in-progress work the user needs to recover

Environment

From local logs / Sentry scope after reproduction:

• Codex Desktop version: 26.422.30944
• Electron: 41.2.0
• macOS: 15.5
• Hardware: Apple M2

What we verified locally

This does not look like a missing-history problem.

1. The thread is recognized and thread/read succeeds

For the problematic conversation ID, multiple local logs show the app registering it as a browser sidebar thread and successfully reading it, e.g.:

• IAB_LIFECYCLE registered browser sidebar thread conversationId=019cb8c6-a2f7-75c0-8e2d-8e1d084334c2
• method=thread/read ... conversationId=019cb8c6-a2f7-75c0-8e2d-8e1d084334c2 durationMs=28
• method=thread/read ... conversationId=019cb8c6-a2f7-75c0-8e2d-8e1d084334c2 durationMs=58
• method=thread/read ... conversationId=019cb8c6-a2f7-75c0-8e2d-8e1d084334c2 durationMs=75

So the content/thread object appears addressable.

2. The thread seems to stall after thread/read, before normal resume completion

When comparing with other browser-sidebar threads in the same logs, healthy threads typically proceed through:

• thread/read
• thread/resume
• maybe_resume_success

For this problematic conversation, we consistently observed thread/read, but did not find the corresponding successful resume completion path for that same conversation ID.

This suggests the failure is in restoring the thread into a live/renderable state, not in locating it.

3. Clearing the local browser-app partition state did not fix it

We explicitly backed up and isolated the browser-app local state under:

~/Library/Application Support/Codex/Partitions/codex-browser-app

We moved out these directories:

• Local Storage
• Session Storage
• Cache
• GPUCache

After restarting Codex Desktop, the exact same thread still reproduced the hang immediately when clicked.

That strongly suggests the root cause is not just stale local browser/sidebar cache. It appears to be either:

• server-side thread/session metadata for this specific conversation, or
• incompatibility between current desktop restore logic and legacy/specific drawing/browser-sidebar thread state

Additional observations

• The app treats this thread as a special browser/drawing/sidebar thread rather than a plain text thread.
• Other browser-sidebar threads do resume normally in the same environment.
• This specific thread appears “poisonous”: clicking it can make the whole app sluggish while never loading historical content.

Request

Could someone investigate the server-side/session metadata for:

019cb8c6-a2f7-75c0-8e2d-8e1d084334c2

The user’s main need is to recover the historical content of that thread if possible.

Local evidence available

We have local desktop logs showing the repeated browser sidebar thread registration and successful thread/read for this conversation ID, plus verification that isolating codex-browser-app local state did not resolve the issue.