What version of the Codex App are you using?
Codex Desktop / ChatGPT desktop app version observed: 26.727.40816
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Windows 11, x64
What issue are you seeing?
A Codex Desktop thread is initially responsive. After referencing/importing a ChatGPT conversation with only about 20–30 turns, that Codex thread becomes persistently sluggish.
The problem is not limited to initial import time. After the conversation is attached, the affected Codex thread remains noticeably slower when opening the thread, scrolling, typing, sending prompts, and continuing work.
This is not an extreme-history case. The referenced ChatGPT conversation is only around 20–30 turns and contains ordinary planning/discussion context, not hundreds of turns or an unusually large repository history.
The impact is larger than a simple performance inconvenience. Codex's paginated history and continuity are useful because a thread can accumulate shared working context, tone, conventions, and conversational continuity over time. Replacing the affected thread with a fresh one avoids some lag, but loses that established continuity. The current behavior forces a choice between keeping an already-established working thread and tolerating persistent UI/performance degradation.
What steps can reproduce the bug?
- Open Codex Desktop on Windows.
- Start or open a normally responsive Codex thread.
- Reference/import an existing ChatGPT conversation containing about 20–30 turns.
- Continue using the Codex thread.
- Observe persistent slowdown in one or more of the following:
- opening or resuming the thread;
- scrolling the transcript;
- typing in the composer;
- sending a prompt;
- receiving or rendering the next response.
- Compare with a fresh Codex thread in the same environment that does not reference the ChatGPT conversation.
What is the expected behavior?
Referencing a moderate-size ChatGPT conversation should not permanently degrade the Codex thread.
The imported conversation should ideally be handled with staged/paginated loading or a compact, traceable working-context projection, while preserving access to the original conversation when needed.
A 20–30 turn referenced conversation should remain practical for normal long-running Codex use.
Actual behavior
The affected thread becomes persistently sluggish after the ChatGPT conversation is referenced. The slowdown remains during later use instead of disappearing after the initial import.
Why this matters
The value of bringing a ChatGPT conversation into Codex is not only transferring task facts. It also preserves shared context and conversational continuity that developed in the original thread. Abandoning the affected Codex thread means losing that continuity, while keeping it means tolerating ongoing lag.
Related issues
This may overlap with broader history hydration and desktop performance reports such as:
However, this report is narrower: the regression is triggered by referencing a relatively small ChatGPT conversation of about 20–30 turns, after which the specific Codex thread remains persistently slow.
Additional information
No customer data, repository contents, private prompts, local paths, or account identifiers are included in this public report.
A sanitized A/B recording can be provided if maintainers need one.
What version of the Codex App are you using?
Codex Desktop / ChatGPT desktop app version observed:
26.727.40816What subscription do you have?
ChatGPT Pro
What platform is your computer?
Windows 11, x64
What issue are you seeing?
A Codex Desktop thread is initially responsive. After referencing/importing a ChatGPT conversation with only about 20–30 turns, that Codex thread becomes persistently sluggish.
The problem is not limited to initial import time. After the conversation is attached, the affected Codex thread remains noticeably slower when opening the thread, scrolling, typing, sending prompts, and continuing work.
This is not an extreme-history case. The referenced ChatGPT conversation is only around 20–30 turns and contains ordinary planning/discussion context, not hundreds of turns or an unusually large repository history.
The impact is larger than a simple performance inconvenience. Codex's paginated history and continuity are useful because a thread can accumulate shared working context, tone, conventions, and conversational continuity over time. Replacing the affected thread with a fresh one avoids some lag, but loses that established continuity. The current behavior forces a choice between keeping an already-established working thread and tolerating persistent UI/performance degradation.
What steps can reproduce the bug?
What is the expected behavior?
Referencing a moderate-size ChatGPT conversation should not permanently degrade the Codex thread.
The imported conversation should ideally be handled with staged/paginated loading or a compact, traceable working-context projection, while preserving access to the original conversation when needed.
A 20–30 turn referenced conversation should remain practical for normal long-running Codex use.
Actual behavior
The affected thread becomes persistently sluggish after the ChatGPT conversation is referenced. The slowdown remains during later use instead of disappearing after the initial import.
Why this matters
The value of bringing a ChatGPT conversation into Codex is not only transferring task facts. It also preserves shared context and conversational continuity that developed in the original thread. Abandoning the affected Codex thread means losing that continuity, while keeping it means tolerating ongoing lag.
Related issues
This may overlap with broader history hydration and desktop performance reports such as:
However, this report is narrower: the regression is triggered by referencing a relatively small ChatGPT conversation of about 20–30 turns, after which the specific Codex thread remains persistently slow.
Additional information
No customer data, repository contents, private prompts, local paths, or account identifiers are included in this public report.
A sanitized A/B recording can be provided if maintainers need one.