Codex tasks regressed from under 5 minutes to 30-50 minutes #28077

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   performance

   on Jun 13, 2026
2. github-actions commented on Jun 13, 2026

   

   github-actionsBot

   on Jun 13, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • GPT-5.5 Fast mode remains extremely slow in Codex 26.609.30741 #27755
   • GPT-5.5 Fast is severely throttled: slower than 1/20 of Standard even after multiple app restarts #27531
   • Severe streaming slowdown in Codex: Fast mode outputs only a few characters every several seconds and then stalls #27491
   • GPT-5.5 Fast spent 12+ minutes thinking, produced no output, then entered reconnecting state #27661
   • Codex Desktop thread becomes extremely slow and recovers after restart #27559

   Powered by Codex Action
3. mazukabz commented on Jun 14, 2026

   

   mazukabz

   on Jun 14, 2026

   Author

   More actions

   Update: the problem is still happening and has become a hard blocker.

   New incident on Jun 14, 2026:

   • User request was a narrow implementation task: adjust generated/current idea-list hook headlines while keeping real film titles on detail pages.
   • Codex worked for 1h 8m 22s and still had not reached the actual edit/verification phase.
   • Most of the visible work was routine context loading/searching: reading project instructions, sessions/INDEX.md, UI kit docs, checking git status, searching for headline/title/composer fields, and reading a handful of backend/frontend files.
   • This is exactly the kind of task that previously would be expected to take around 5 minutes, not more than an hour.

   This is now blocking normal use of Codex for day-to-day project development. Please escalate/triage as a serious performance regression in the Codex desktop app / agent runtime, not just a one-off slow task.

   Codex app version: 26.609.41114, released Jun 12, 2026.
4. vicentesurraco commented on Jun 14, 2026

   

   vicentesurraco

   on Jun 14, 2026

   Last edited by vicentesurraco

   More actions

   +1 - its been extremely slow for several days on desktop. CLI is still fast
5. SREDevOpsNL commented on Jun 16, 2026

   

   SREDevOpsNL

   on Jun 16, 2026

   More actions

   +1 — I am seeing a very similar regression, but on a newer Codex Desktop version.

   Codex app version:
   26.609.71450, released Jun 16, 2026

   Platform:
   Windows, Codex desktop app

   Account:
   Personal ChatGPT Plus account

   Feedback ID:
   019e97a5-b545-7641-bcec-cfcd9b53fca2

   Issue:
   After updating to 26.609.71450, Codex started over-expanding narrow tasks and spending a very long time on work that should be a small maintenance fix.

   Concrete case:
   I asked Codex to fix a simple smoke-test video artifact path mismatch.

   Original request, shortened/sanitized:

   Video of a demo smoke test run is moved to another folder:
   <repo>\test\test-results\smoke-artifacts\pvw-ui-smoke-demo\20260614-013147\01_PVW-US-09-...\playwright\videos\<test-name>\<hash>.webm

   Please check that smoke tests use again:
   <repo>\test\test-results\smoke-artifacts\pvw-ui-smoke-demo\20260614-013147\01_PVW-US-09-...

   where 20260614-013147 is DateTime-UniqueNumber specific to that test run.

   Expected behavior:
   Codex should keep the task narrow:

   • identify why the raw Playwright video remains nested under playwright\videos\...;
   • copy/promote the reviewer-facing video back to the scenario folder root, e.g. demo.webm;
   • make the minimal code/path fix if needed;
   • stop after minimal verification.

   Actual behavior:
   Codex worked for 3h 20m 33s and still did not properly complete the simple requested fix. It drifted into broader, unnecessary work such as:

   • reading startup/project context;
   • investigating runner behavior too broadly;
   • improving timestamp collision handling;
   • editing docs/runbooks;
   • editing review-pack notes;
   • changing more files than needed for the immediate path mismatch.

   Codex later admitted the scope drift itself:

   “You’re right to be angry. I overworked a simple artifact-path fix.”

   “I correctly identified that the raw Playwright video was nested under playwright\videos\<test-name>\<hash>.webm.”

   “I did copy it to the scenario root as demo.webm.”

   “Then I drifted into ‘improving’ the runner, docs, timestamp collision handling, and review-pack wording. That was not necessary for the immediate fix.”

   Impact:
   This consumed a large amount of Codex quota and made the desktop app unreliable for small maintenance tasks. The issue is not only raw slowness; it is also task-scope drift combined with very long agent runtime.

   Why I think it is related to this issue:
   The visible behavior matches the regression described here: narrow tasks that previously should have taken a few minutes now take tens of minutes or hours, with long stretches of context loading/searching/tool work before reaching the actual edit/verification phase.

   Request:
   Please treat this as a serious Codex Desktop agent-runtime regression affecting:

   • task scoping;
   • no-progress detection;
   • excessive context loading;
   • long-running task control;
   • quota consumption for small tasks.

   I have uploaded in-app feedback from the affected Codex session.

   Feedback ID:
   019e97a5-b545-7641-bcec-cfcd9b53fca2
6. SREDevOpsNL commented on Sep 25, 2026

   

   SREDevOpsNL

   on Sep 25, 2026 – with ChatGPT Codex Connector

   Last edited by SREDevOpsNL

   More actions

   Additional quota-consumption regression report.

   Codex app version: 26.917.71314
   Platform: Windows, Codex desktop app
   Timezone: CEST / UTC+02

   Issue:
   After resetting my Codex usage limit, the 5-hour usage bucket was exhausted again in about one hour of wall-clock time while using medium effort. This happened across only three tasks in two different projects.

   Environment / permissions:
   Codex had normal configured access to the relevant project/workspace files. This does not look like a simple permission/access limitation: Codex was able to read project files and continue work, but usage was consumed extremely quickly.

   Timeline:

   • 20:58 CEST — reset the Codex usage limit.
   • Continued a stopped task named “Create Frontend UI Architecture”. Effort: medium. Duration: 21m 17s. Outcome: completed.
   • Created a new task named “Locate L01 and L02 course work”. Effort: medium. Duration: 4m 55s. Outcome: completed.
   • 22:08 CEST — in another project, VerityHub, continued another task. Effort: medium. After about 12 minutes, hit the Codex usage limit again.

   Observed usage state after the incident:

   • Usage remaining: 0%
   • 5h: 0%, reset at 1:55 AM
   • Weekly: 84%, reset Oct 2
   • gpt-reserve weekly: 100%, reset Oct 2

   Impact:
   The 5-hour usage limit went from reset/full to exhausted in about one hour of wall-clock time using medium effort, across only three tasks. The visible task runtime was roughly 38 minutes total, and weekly usage also dropped by about 16%. This feels disproportionate for medium-effort work on a small number of tasks.

   Why I think this is related:
   This looks related to the recent Codex Desktop performance/throughput regression reports, but in my case the issue is specifically quota consumption. The visible work does not explain why the 5-hour bucket was exhausted so quickly after a reset.

   Expected behavior:
   A freshly reset 5-hour usage bucket should not be exhausted after a few medium-effort tasks unless there is a clear explanation in the usage UI. If hidden context processing, retries, compaction, reconnects, or background work consume quota, the UI should expose that clearly.

   Request:
   Please investigate whether recent Codex Desktop versions have a regression in quota accounting, excessive hidden context processing, task runtime accounting, context compaction/retry behavior, medium-effort usage consumption, or cross-project usage tracking after a reset.

   I can provide screenshots and in-app thread IDs if needed.

   Feedback IDs:

   • 01a0c9b9-f548-7510-8b5d-318fe1427620
   • 01a04e84-b665-7b62-8801-80556a14e595
7. semtrak commented on Sep 29, 2026

   

   semtrak

   on Sep 29, 2026

   More actions

   Im seeing the same on the latest codex version. very similar issue. on Mac using codex app current version sep 29,2026

   Title: Simple Markdown edit becomes a 40+ minute agent workflow and consumes shared usage
   I asked Codex to add one paragraph to an existing Markdown document. The paragraph itself was straightforward and Codex appeared to understand and draft it immediately. Instead of making that single edit and showing me the result, the task continued running for more than 40 minutes.
   The activity displayed:

   • “Ran commands”
   • “Context automatically compacted”
   • Running /bin/zsh -lc 'git fetch origin …'
     The same git fetch status remained visible for an extended period with no explanation, progress, completion, or request for input. Fetching the remote repository was unnecessary for this local one-paragraph documentation edit.
     Expected behavior:

   1. Open the referenced Markdown file.
   2. Read the surrounding section.
   3. Insert the requested paragraph.
   4. Show the exact change or diff.
   5. Finish within a few minutes.
      Actual behavior:

   • Codex expanded a small edit into an opaque repository workflow.
   • It ran unrelated Git operations.
   • It automatically compacted context during a trivial task.
   • It provided no useful indication of whether it was progressing or stalled.
   • I could not directly edit or copy the proposed text to complete the task myself, as I could in the previous interface.
   • The runaway task consumed time and potentially shared ChatGPT Work/Codex usage, reducing the usage available for productive work later.
     This is part of a broader regression I am experiencing after the recent release: small, explicit requests now trigger long autonomous workflows, direct user control has been reduced, and instruction drift or invented evidence makes the output less trustworthy. A task I could previously complete in seconds has become a 56+ minute process - still running. I reported the bug through feedback.
     Please investigate the task execution trace, particularly why a local Markdown edit invoked git fetch origin, why that command appeared to stall, why context compaction was required, and how much shared usage the failed run consumed. Please restore a fast path for small edits and an editable/copyable result that lets the user intervene without waiting for the agent workflow to finish.