codex attach the chatgpt conversations as the context to send

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

• #31966

Powered by Codex Action

Additional reproduction: local UI freezes, but the task is successfully accepted and continues remotely

I am seeing the same issue when using the official ChatGPT-to-Codex conversation handoff.

This is not caused by copying and pasting a large prompt into the composer. It happens when I use the official ChatGPT conversation reference / Add to task flow to initialize a Codex task from an existing ChatGPT discussion.

Observed behavior

1. I select an existing, relatively substantial ChatGPT discussion and use the official Add to task flow.
2. I submit the initial task to Codex.
3. The local Codex conversation UI immediately stops updating:

• no response or trace is rendered in the conversation pane;
• the composer becomes unusable or appears stuck;
• the Pet still indicates that the task is active.

1. The task has actually been accepted:

• the Remote control/view shows continuing task progress;
• the background task continues executing normally.

1. Because the local UI provides no reliable “task accepted” acknowledgement, I previously assumed that submission had failed and sent the task multiple times.
2. This resulted in duplicate tasks running, wasted usage/quota and time, and a risk of multiple agents modifying the same workspace concurrently.

The issue is intermittent but has happened more than once. I have not observed the same failure mode in the CLI; it appears specific to the Desktop ChatGPT conversation handoff and local conversation-rendering path.

Why this is more serious than a visual freeze

The local UI communicates that submission may have failed, while the runtime has already accepted and started the task. This can directly cause duplicate execution and additional usage costs.

The Pet and Remote state prove that the runtime remains alive, so the failure appears to affect the local conversation/composer rendering or task-state synchronization rather than task execution itself.

Expected behavior

At minimum, the app should:

• display a durable “task accepted” acknowledgement and task identifier immediately after submission;
• continue showing that the task is running even if the conversation renderer fails;
• prevent or warn about repeated submission of the same referenced conversation and prompt;
• allow the local UI to reattach to the already-running task without terminating it;
• expose a recovery or reload action that does not kill the background task.

Environment

• Codex App version: 1.2.35 (build 1.2.35)
• macOS version: 26.5.2
• Architecture: arm64
• Subscription: Team
• Approximate occurrence date: 2026-07-18

I can provide additional diagnostics if there is a recommended safe method for collecting renderer, app-server, or task-handoff logs.

I can reproduce this issue on macOS using the same ChatGPT “More details” → “Add to task” workflow.

Environment:

• Codex App: 26.715.72028 (build 5706)
• Also reproduced on: 26.715.71837
• Platform: Darwin 25.5.0 arm64 arm
• Subscription: ChatGPT Plus
• Feedback ID: 019f8869-dbbd-7673-b4dc-417c2ba776e7
• Affected Codex thread ID: 019f8856-1e6e-7c63-ba50-776ebc97c330

Additional reproducible behavior:

1. Select text in a ChatGPT response.
2. Open “More details”.
3. In the lower-right Chat pop-up, choose “Add to task”.
4. Send the generated Codex request containing the referenced ChatGPT conversation.
5. The entire Codex desktop window becomes non-interactive. The sidebar, task list, stop button, composer, and thread content cannot be clicked, although the native macOS application menu remains responsive.
6. At the same time, the submitted task continues running normally and remains visible through mobile remote access, including approval prompts.
7. After the background task completes, quitting and restarting Codex does not repair the affected thread.
8. Clicking the affected thread immediately freezes the desktop UI again. The thread may appear as an empty “New task”, even though its stored content is still intact.

This has occurred on at least two separate occasions several days apart, both through the same ChatGPT conversation-reference workflow.

During local diagnosis, the affected turn was found to have completed successfully with no turn error. thread/read and thread/resume also returned quickly and without errors, after which the main renderer stopped processing the thread while the backend and mobile interface remained active. No new Crashpad crash report was generated.

A replacement task containing the useful content as plain text, without the ChatGPT conversation reference, loads normally. The affected task has been archived rather than deleted.

Comment draft for openai/codex issue #32033

---

Same issue on Windows. I traced it and I think I have the root cause plus a workaround.

Environment

• Codex / ChatGPT desktop app 26.721.41059 (Windows 11)
• codex CLI 0.146.0

Symptom

Sending a ChatGPT conversation reference into Codex does nothing — both via Add to task and by pasting the link into the composer manually. The send button turns into a disabled spinner and never comes back. Repeating it eventually leaves the whole window unresponsive with the fan spinning up, which matches what #32342 describes.

It never reaches the backend

I went through several hours of ~/.codex/logs_2.sqlite across four reproductions. On every failed send the pattern is identical:

• the app-server receives config/read and configRequirements/read (~30 ms apart), and then nothing
• no codex.op="user_input" submission is ever dispatched
• the app-server stays completely idle afterwards — only account/read / skills/list polling

So the backend never sees the message at all. The high CPU is not the app-server; it is idle throughout. The submit is being blocked inside the renderer, before any RPC is emitted.

The blocker is the unresolved conversation chip

The composer stores the reference as a markdown link with a custom scheme:

[<conversation title>](chatgpt-conversation://<uuid>)

Its leading icon stays an unfilled ring (loading state) indefinitely — the reference never finishes resolving. While it is in that state the composer refuses to submit, disables the send button, and shows no error anywhere.

Workaround

Delete the conversation chip from the composer, then send. Confirmed on my machine: with the chip removed, the exact same message dispatched immediately and codex.op="user_input" appeared in the log within milliseconds.

One gotcha — the draft is persisted to disk, so restarting the app does not clear it. It comes back. It lives in ~/.codex/.codex-global-state.json under composer-prompt-drafts-v1.

Possibly relevant: the same draft is stored under two keys for the same thread — the pre-creation client-new-thread:<uuid> id and the post-creation local:<thread-id> id, which are linked by a thread-client-id-v1:... entry in the same file.

Suggestions

• Time out or fail the chatgpt-conversation:// resolution with a visible error, instead of leaving the chip in a loading state forever
• Don't silently disable submit with no indication of what is blocking it
• A way to clear a stuck chip without hand-editing the state file would help

Happy to provide more log detail if useful.

---

Log analysis and root-cause investigation done with Claude Opus 5.