Codex desktop freezes on tasks continued from ChatGPT conversations

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #32342

Powered by Codex Action

I investigated the affected local sessions and found a more specific failure boundary. This case is most consistent with a Desktop renderer route/stream handoff regression, not a model context-window overflow.

Environment

• ChatGPT/Codex Desktop: 26.707.72221 (build 5307)
• Bundled Codex app-server: 0.144.2
• macOS, Local host
• Folder: the same md-resume folder from the original report

Decisive A/B evidence

For the first two affected tasks, app-server accepted thread/start and turn/start, and the rollouts continued through reasoning and local tool calls. However, the Desktop primary renderer never bound the newly created canonical thread:

• Missing thread_stream_view_activity_changed active=true
• Missing ownerRoutePath=/local/<canonical-thread-id>
• One failure explicitly remained at conversationId=client-new-thread:... with ownerRoutePath=/
• Reasoning/activity events were delivered only to rendererWebContentsId=2 rendererWindowAppearance=avatarOverlay, while the primary task view did not become the active owner

A normal task created in the same folder and same Desktop build followed the expected sequence:

Conversation created
-> stream role owner
-> active=true
-> ownerRoutePath=/local/<canonical-id>
-> route reassign/rebound
-> turn/start
-> maybe_resume_started

The imported failures stop after create/owner/turn-start without the canonical route activation and stream rebound. This explains why the backend can keep working while the main task UI appears frozen.

Task-specific observations:

• 019f647f-92d4-7b22-af3b-705fa2624e81: backend reasoning/tool activity continued; no canonical route activation
• 019f6484-7d0c-79f0-be4b-9a8e87e1a394: owner sync still referenced client-new-thread:... and route /
• 019f649f-2560-7760-8e20-fc5cccb788df: turn/start succeeded, but the rollout stopped at session_meta + task_started, before context materialization/model execution

A ChatGPT-imported task on the previous Desktop build 26.707.71524 completed normally and had the full route lifecycle above. Both builds used bundled app-server 0.144.2, which further points to a Desktop renderer/shell regression introduced between those app builds.

Context-size finding

The referenced ChatGPT conversation is serialized into one user input:

• 12 conversation messages
• 40,782 Unicode characters / 58,198 bytes
• 294 triple-backtick sequences
• No sandbox:, sediment://, generated-file attachment, or citation references

The packaged renderer builds this context by JSON-serializing the full referenced conversation without an apparent size/complexity budget. That is a separate hardening gap and may amplify renderer work, but it is not a hard context limit in this reproduction: the affected requests were approximately 51K tokens against a 258.4K context window. One failed task stalled with zero model tokens.

Suggested internal fix/test

When ChatGPT handoff returns the canonical thread ID, atomically:

1. replace the transient client-new-thread:* route with /local/<canonical-id>;
2. mark the canonical thread view active;
3. rebind stream ownership before starting/rendering the turn;
4. on failure, roll back the transient task and show a recoverable error instead of leaving a poisoned task.

Please add a regression test for Continue from ChatGPT using a multi-message, code-heavy referenced conversation, asserting the canonical route, active view, stream owner, visible progress, and recoverable bootstrap failure.

This overlaps the visible symptoms in #31966, #32342, #32996, and #33008, but this local reproduction does not require legacy attachment hydration; the canonical route/stream handoff is the clearest differentiator.

Additional reproduction with stronger evidence that the failure is in the ChatGPT → Work/Codex handoff and desktop rendering path.

Environment

• macOS ChatGPT desktop: 26.715.31925 (build 5551)
• Windows 11 ChatGPT desktop: current installed build (exact version not captured)
• Host: Local
• The same affected generated tasks freeze the desktop UI on both macOS and Windows 11
• The remote task continues running and can still be followed from a smartphone, which suggests the backend task itself remains alive

Affected task IDs

• 019f7623-377b-78d0-93a0-3600ad0607b8
• 019f71ba-f829-75e3-b210-ee7944d3d742

The user explicitly approved including these IDs for internal investigation. Raw conversation contents are intentionally not attached because they contain private data.

Sanitized thread measurements

Inspection without opening the affected tasks in the desktop renderer shows that the automatic handoff embeds the full source conversation under "Referenced ChatGPT conversation" inside the first Work/Codex user message.

| Task | Serialized thread size | Largest single user message | Preview/title length |
| --- | ---: | ---: | ---: |
| 019f7623… | 652,709 chars | 604,300 chars | 2,833 chars |
| 019f71ba… | 640,674 chars | 575,062 chars | 4,162 chars |

Two smaller converted samples also contained the full referenced conversation:

• 126,849-char thread / 111,590-char largest user message
• 72,114-char thread / 48,723-char largest user message

A normal non-converted control task was only 16,436 serialized chars, with a largest user message of 200 chars and no embedded referenced conversation.

Observed behavior

1. Start from a long regular ChatGPT conversation.
2. Accept the prompt to continue/switch to Work.
3. A Work/Codex task is created and can continue remotely.
4. Opening that generated task in the desktop app freezes the entire UI.
5. Closing and reopening the app does not help because selecting/restoring the same synced task triggers the freeze again.
6. The same task reproduces on both Windows 11 and macOS.

On macOS, the freeze correlated with a burst of 1,338 renderer communication warnings in roughly 60 ms, including:

• Failed to publish app update state to renderer
• MessagePort message error

The window/renderer was reported as no longer live. This log correlation may be secondary to the oversized handoff payload, but it is consistent with a renderer-side failure rather than a backend model failure.

Suspected cause

The ChatGPT → Work conversion appears to copy the entire source conversation into one user message rather than producing a bounded handoff summary. Long source chats therefore create 0.5–0.6 million-character message payloads, oversized previews/titles, and synchronous renderer work that can make the whole desktop window unresponsive.

Expected behavior

• Use a compact/bounded handoff summary rather than embedding the complete source conversation into one message.
• Cap preview/title generation.
• Lazy-load or virtualize large referenced history.
• If a generated task exceeds safe limits, isolate the failure to that task and show a recoverable error instead of freezing the entire application.

Current workaround

Create a clean Work task and manually provide a concise summary; avoid opening the affected generated task in the desktop app.

Potentially related: #32342, #32666, #33016, #25430.

Independent macOS reproduction on a newer build, with a concrete failure response from the ChatGPT conversation fetch path.

Environment

• ChatGPT/Codex Desktop: 26.715.72359 (bundle build 5718)
• Platform (uname -mprs): Darwin 25.3.0 arm64 arm
• macOS: 26.3.1 (25D771280a)
• Host: Local
• A second Mac also reproduces the handoff failure; its exact app/OS versions were not captured.

Steps to reproduce

1. Open an existing ChatGPT conversation in the unified desktop app.
2. Use the ChatGPT → Codex handoff/reference flow to create a Codex task from that conversation.
3. Submit/create the task.
4. Observe the task-creation result.

Actual behavior

On the first Mac, task creation fails and the app displays raw HTML under “Error while creating task” instead of creating the task. The response is a Cloudflare managed challenge page returned for a redacted ChatGPT conversation endpoint:

<html>
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    ...
  </head>
  <body>
    ...
    <noscript>
      <span id="challenge-error-text">Enable JavaScript and cookies to continue</span>
    </noscript>
    ...
    cZone: 'chatgpt.com'
    cType: 'managed'
    ...
    /backend-api/conversation/<redacted-conversation-id>
  </body>
</html>

Because no Codex thread is created, the uploaded feedback is associated with:

no-active-thread-019f8a65-e4f9-7933-ba2d-6ab5e4a111c7

On the second Mac, the same ChatGPT → Codex flow makes the desktop app hang instead of showing the HTML error.

Expected behavior

The referenced ChatGPT conversation should be fetched and converted into a Codex task successfully. If the request is challenged or returns non-JSON HTML, the app should recover by re-authenticating/retrying or show a concise actionable error. It should not render the raw challenge page or become unresponsive.

Additional observation

The captured response strongly suggests that at least one failure occurs before normal task/thread initialization: the request to /backend-api/conversation/<id> receives a Cloudflare JavaScript/cookie challenge instead of conversation JSON. This may be a separate trigger that reaches the same user-visible handoff failure described in this issue.