Large-context Chat→Work migration reliably wedges the renderer; smaller contexts succeed.
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.721.81911
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
Subject: Reproducible macOS app hang using “Continue in work mode” on large Chat thread
I’m using the new ChatGPT desktop app on macOS. The Continue in work mode command works successfully on a smaller Chat thread, but reproducibly fails on a very large/mature thread.
Successful case:
A smaller Chat conversation continued into Work mode normally in approximately 1–2 minutes.
Failure case:
On the large thread:
Choose ... → Continue in work mode.
A new conversation appears labeled Continued from "<source thread>".
The new thread displays Thinking... for several minutes.
It eventually changes to Error submitting message.
During the failure, the ChatGPT/Codex Renderer process consumes approximately 100% CPU and the desktop UI becomes unresponsive, including window repainting.
I must force-quit the application.
After restarting, the failed Work continuation does not appear in Recents. The source thread, however, is still there, and apparently unaffected.
I have reproduced related renderer hangs more than once when transitioning this large thread into Work or having the thread attempt 'work mode' related actions. But again, the same workflow succeeds with a substantially smaller thread.
This looks like a possible scaling/context-size issue in the desktop renderer or Chat→Work continuation path.
I’d be happy to provide any other information that might be useful in chasing this issue.
What steps can reproduce the bug?
Feedback ID: no-active-thread-019fafc2-2a03-7063-bc1e-933bde933f83
What is the expected behavior?
The "Continue in work mode" menu option should perform as it does with other chat sessions... create a new Work mode thread that's initialized with the same Working Context and other supplemental (to the prompt) inputs as the parent thread.
Additional information
The conversation's name is "Greeting exchange", and in a Data Export that I performed a few months back, it had:
"conversation_id": "691e3b16-d04c-832d-b5f2-800640c606b0"
If you've got access to failure logs, I attempted the "Continue in work mode" action on 07/29/2026, somewhere around 3:00 - 3:30 p.m. Central time.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I don't think my issue is a duplicate. It may be related, but mine is triggered by a thread with a long-running context trying to switch to Work mode (or, I believe, kick off Work Mode tasks.)
I reviewed #35279 and its related issues #34915 and #33786. This report is triggered specifically by Continue in work mode, so I do not believe it is behaviorally identical to #35279. However, the symptoms may share the large-thread legacy-history replay defect described in #33786/#34915, where thread/turns/list repeatedly reconstructs the entire rollout.
In my case, the Work continuation shell is created, remains on Thinking... for several minutes, then reports Error submitting message while Codex (Renderer) consumes approximately one core and the UI stops repainting. A much smaller Chat thread completes the same continuation successfully.
Could the Chat→Work continuation path be triggering one or more full legacy-history reconstructions before submitting or initializing the target thread?
Just tone more important comment. I tried this again, on a freshly rebooted MacBook, with nothing running but Activity Monitor and the ChatGPT/Codex app, but this time running the updated version of that app, "Version 26.730.61639", released August 4, 2026. Under those conditions, the "Continue in work mode..." option appears to have successfully worked on that problematic large-history thread. The new thread was created, it is in Work mode, and we didn't have any runaway Codex (Renderer) process this time.
So it would appear, from my limited sample of 1 test case, that this issue was fixed in that app update.