›_ Codex Issues
Codex Issues / #37233

Referencing a 20–30 turn ChatGPT conversation makes a Codex Desktop thread persistently sluggish

Open 💬 3 comments Opened Aug 6, 2026 by vbzgn2rc98-ctrl
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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?

  1. Open Codex Desktop on Windows.
  2. Start or open a normally responsive Codex thread.
  3. Reference/import an existing ChatGPT conversation containing about 20–30 turns.
  4. Continue using the Codex thread.
  5. 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.
  1. 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:

  • #21211 — Thread navigation/loading slows from unbounded metadata and eager large-history hydration
  • #20214 — Codex App frequently freezes/stutters on Windows 11 Pro despite sufficient system resources

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.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 22 days ago

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

  • #36071

Powered by Codex Action

vbzgn2rc98-ctrl · 20 days ago

Reviewed #36071. It appears closely related, but my case is not an exact match in observed behavior.

In #36071, sharing a longer ChatGPT chat as Codex context causes the app to freeze during the transfer and become unrecoverable. In my case, a moderate ChatGPT conversation of only about 20–30 turns imports successfully and the Codex thread remains usable, but that specific thread becomes persistently sluggish afterward (opening/resuming, scrolling, typing, sending prompts, and continuing work).

This may be a less severe manifestation of the same underlying hydration/import problem, so I am leaving this issue open for maintainers to correlate or mark as a duplicate if appropriate.

One additional user-impact point: even if an affected thread becomes too heavy, a supported way to fork/migrate the current conversational state into a fresh responsive thread while preserving established conversational continuity would substantially reduce the impact. A fresh thread can restore performance, but today it also loses the shared working context, conventions, tone, and continuity that made the existing thread valuable.

leadingproblemsolver · 20 days ago

One useful way to separate the performance problem from the continuity problem is to stop treating an imported ChatGPT conversation as live thread history after import.

I would model it as two layers:

  1. Immutable source corpus — the imported conversation remains addressable in full, but is not eagerly hydrated/rendered/replayed on every Codex turn.
  2. Derived working-context projection — a bounded set of active facts, decisions, constraints, unresolved questions, conventions, and next actions, where every derived item keeps a source pointer back to the imported conversation.

Then Codex only carries the projection plus a small recent raw tail in the hot path. If the agent needs detail, it resolves the source pointer on demand rather than rehydrating the whole imported chat.

The important invariant is that the projection must be traceable, not just a lossy summary. A useful record shape is roughly:

item_id
kind = decision | fact | constraint | unresolved | convention
normalized_text
source_conversation_id
source_turn_id / source_range
source_hash
status = active | superseded | stale

That also gives a much safer migration/fork path: create a fresh responsive thread from the current projection while retaining the imported conversation as an immutable evidence source. Continuity survives without forcing UI/history hydration to carry the entire source transcript.

This is the exact boundary I have been testing in a small local-first project-memory compiler: ingest files/conversation-like sources, derive operational state into SQLite, and keep source provenance on every derived record so the compact view can always be checked against its origin: https://github.com/leadingproblemsolver/living-context-engine

For this issue specifically, I would measure three things independently after import: renderer/history bytes, model-visible context bytes, and derived-projection bytes. If only the first two grow with source size while the projection remains bounded, the architecture is doing the right thing.