Codex gets stuck in a pre-write context compaction loop on large projects, repeatedly re-reading instructions and never reaching file edits

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.608.12217 • Released Jun 9, 2026

What subscription do you have?

ChatGPT Pro, $200/month

What platform is your computer?

Windows 11 x64, Version 10.0.26200.8524

What issue are you seeing?

Hi Codex team,

I want to share product feedback from a real long-running Codex project. This is not about model quality. The model often reasons correctly. The problem is task execution reliability and state management in large projects with many project instruction files.

Issue summary:
Codex can get stuck for hours before making any file changes. In my case, a simple single-game data processing task ran for 2–4+ hours, but no files were edited. The task repeatedly entered the same loop:

1. Read project hot files / rules.
2. Read lock / registry / state files.
3. Context automatically compacted.
4. Reconnect / stream interruption happens.
5. Codex resumes and re-reads the same files again.
6. It never reaches the actual write/action phase.

Example repeated pattern:

• “Continuing with one case…”
• “First I will check lock and current versions…”
• “Reading START_HERE / PROJECT_STATE / ACTIVE_TASK / CANONICAL_PATHS…”
• context compaction
• same sequence repeats again

Observed error:
stream disconnected before completion: websocket closed by server before response.completed

Why this matters:
For project/file-editing tasks, this is dangerous because the UI may show the task as working for hours, but the backend never reaches a durable write phase. The user cannot tell whether:

• the task is still valid,
• it is stuck in preflight,
• files were partially written,
• or the task should be stopped.

This becomes especially painful in projects with many instruction files, ledgers, registries, and safety rules. Codex appears to treat every reconnect/context compaction as a reason to re-run the full preflight, instead of resuming from a durable phase marker.

Expected behavior:
Codex should detect this loop and stop safely.

Suggested improvements:

1. Add automatic pre-write loop detection.

If Codex reads the same instruction/state files multiple times without file edits or new useful output, it should stop and write a short status report.

1. Add explicit task phase tracking.

For example:

• preflight_started
• preflight_done
• write_started
• validation_started
• final_report_started
• completed

After context compaction or reconnect, Codex should resume from the last durable phase instead of restarting preflight.

1. Add a “write status report and stop” recovery action.

This would be very useful when the UI stream disconnects but the project state is unclear.

1. Add a hard time/no-progress guard.

Example:
If no files were edited after 10–15 minutes in a file-editing task, Codex should ask whether to continue or stop with a report.

1. Improve WebSocket disconnect handling.

When websocket closed before response.completed happens, the UI should clearly show:

• backend still running,
• backend completed,
• backend failed,
• stream only failed,
• project state unknown.

1. Support lightweight fast-path modes.

For small repeatable workflows, users need a way to tell Codex:

• do not re-read all policies,
• read only these exact files,
• do not run broad search,
• stop if exact paths are missing.

Current workaround:
I had to redesign my workflow around lightweight “analysis packets” instead of asking Codex to fully integrate every data point, because full integration often triggers long preflight loops.

Impact:
This makes Codex much less reliable for large project workflows, even on higher reasoning / faster settings. The issue is not just speed. It is that the agent can spend hours preparing to work without reaching the actual work.

Thank you. I hope this helps improve Codex’s long-running project reliability.

What steps can reproduce the bug?

Reproduction steps

This is a Codex App issue during long-running local project/file-editing tasks on Windows.

No code snippet is required to reproduce it. The issue happens while Codex is asked to edit a local project with multiple Markdown/JSON project instruction files, ledgers, registries, and status files.

Environment:

• OS: Windows 11
• Codex: Codex App / Codex inside ChatGPT
• Model: GPT-5.5
• Reasoning mode: Extra High
• Speed mode: Fast
• Project type: large local Codex project with many Markdown/JSON files
• Git: either unavailable in PATH or explicitly disabled in the prompt

Steps to reproduce:

1. Open a large Codex project on Windows with multiple project instruction/status files, for example:

• _codex/00_START_HERE.md
• _codex/01_ACTIVE_TASK.md
• _codex/02_PROJECT_STATE.md
• _codex/indexes/CANONICAL_PATHS.md
• _codex/rules/*.md
• _case_queue/*.jsonl
• _case_queue/CURRENT_CASE_LOCK.json
• runtime/registry JSON files

1. Ask Codex to perform a small scoped file-editing task, for example:

• read the current lock file;
• process exactly one input item
• do not use old chat memory;
• do not run Git commands;
• do not run broad project search;
• write one small report and stop.

1. Codex starts correctly, but before reaching the actual write phase it repeatedly reads the same project “hot files” and rules:

• START_HERE
• ACTIVE_TASK
• PROJECT_STATE
• CANONICAL_PATHS
• lock / registry / ledger files
• policy/rule files

1. Context compaction happens automatically before the task reaches a durable write/edit phase.

1. After compaction, Codex resumes and starts the same preflight again:

• “Continuing with one case…”
• “First I will check the lock and versions…”
• “I will read the project hot files…”
• “I will not process old cases…”
• then it reads the same files again.

1. This repeats many times. In one case, the task ran for more than 2 hours with no file edits at all. In another case, a small task ran for more than 4 hours.

1. During this loop, the UI often shows:

• Reconnecting /5
• stream disconnected before completion: websocket closed by server before response.completed
• Context automatically compacted

1. The task state becomes ambiguous. It is not clear whether:

• the backend task is still running;
• the task failed;
• the UI stream failed but backend continued;
• some files were partially written;
• or Codex is stuck in a pre-write loop.

Expected behavior:

• Codex should not repeat the same preflight indefinitely after context compaction.
• Codex should detect that it has read the same files multiple times without progress.
• Codex should either proceed to the write phase or stop safely with a status report.
• After a WebSocket disconnect, the UI should show whether the backend task is still running, completed, failed, or unknown.

Actual behavior:

• Codex can spend hours in a pre-write loop.
• It repeatedly re-reads the same project files after context compaction.
• It often disconnects with websocket closed by server before response.completed.
• The UI does not clearly indicate the real backend task state.
• No durable status report is always produced before the stream disconnects.

Impact:

• Long-running Codex project tasks become unreliable.
• The user cannot tell whether the project state is clean.
• Recovery prompts are required after many tasks.
• Usage/time is consumed without meaningful file edits.
• It becomes unsafe to queue follow-up tasks because the previous task state may be ambiguous.

Suggested improvement:

• Add automatic pre-write loop detection.
• Track task phases durably: preflight_started, preflight_done, write_started, validation_started, final_report_started, completed.
• After reconnect/context compaction, resume from the last durable phase instead of restarting preflight.
• Add a “write status report and stop” recovery action.
• Add a hard no-progress guard, for example: if no files are edited after 10–15 minutes in a file-editing task, ask whether to continue or stop.
• Show clearer backend state after WebSocket disconnect:

• backend still running;
• backend completed;
• backend failed;
• UI stream failed only;
• project state unknown.

Approximate context/token usage: it start happening around week ago, PRO /200USD run out less than a week :( It felt less by how fast token use then when i started on 100USD

Attachments:
I can attach screenshots showing:

• Reconnecting /5
• websocket closed by server before response.completed
• repeated Context automatically compacted
• task running for hours with no file edits
• repeated preflight messages

What is the expected behavior?

_No response_

Additional information

_No response_