openai / openai/codex

No Result or bad results

Open
#38,607 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app bug model-behavior rate-limits subagent
Dominant language
Rust
Stars
125k
Forks
19.5k
PR merge metrics
PR metrics pending

Description

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

I am using n-1 version when the issue happened.

What subscription do you have?

ChatGPT Pro (200$ one)

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

I am a ChatGPT Pro user and use Codex extensively for development of a production application.

I am requesting an investigation into two recent long-running Codex agentic/Goal executions that consumed a very substantial portion of my available usage while failing to deliver results proportionate to the work performed.

I am specifically requesting:

Review of the Codex execution/session telemetry for both incidents.
Restoration/credit of the Codex usage consumed by the failed/non-convergent executions, where appropriate.
One Codex rate-limit reset, if available, so that I can continue the development work affected by these executions.
Escalation of the incidents as an agentic execution/convergence issue.

Incident 1 — Production Hierarchy Integrity Hotfix

Approximate execution duration: 13 hours

This task was not initiated with a short or open-ended prompt. I provided a detailed implementation plan defining:

task boundaries and dependency order;
separate worker ownership and worktrees;
explicit implementation files;
tests and validation commands;
coordinator/integration responsibilities;
security and production boundaries;
review requirements;
explicit stop conditions;
Critical/High review thresholds;
production approval gates.

Despite this, after approximately 13 hours, the actual integration branch still contained no functional hierarchy hotfix from the substantive implementation tasks.

When I challenged the lack of progress, Codex itself performed a retrospective and stated:

“The central mistake was that the implementation became a project to build and verify a PostgreSQL/PLpgSQL parser inside a test file, instead of completing the hierarchy hotfix.”

Codex further reported that a single test file had grown to approximately 3,287 lines, and acknowledged:

“I converted ‘no disposable database’ into ‘simulate PostgreSQL locally.’”

It also acknowledged:

“I applied the wrong blocking threshold.”

The supplied implementation plan required resolution of Critical/High review findings before integration. Codex acknowledged that it instead repeatedly treated additional “Important” findings in test-only auditing machinery as integration blockers.

Most importantly, Codex concluded:

“I let a bounded source contract become an exhaustive parser, treated non-runtime Important findings as mandatory blockers, and failed to stop when the process stopped converging.”

This resulted in many hours of model/agent execution and usage consumption without the intended production fix reaching the integration branch.

Incident 2 — AttendWise Kiosk UI Pixel-Parity Goal

Approximate execution duration: 20 hours

This task also had a detailed implementation plan rather than an open-ended request.

The plan included:

six explicitly defined UI layout families;
a frozen 70-state visual atlas;
eight defined target viewports;
objective geometry tolerances;
a maximum screenshot-difference threshold;
strict file ownership between agents;
protected files that could not be modified;
explicit model assignments;
maximum concurrency;
token/context controls;
bounded task briefs;
a maximum number of repair rounds;
deterministic visual fixtures;
integration order;
browser/device QA requirements.

The plan specifically instructed agents not to reread the complete repository or all 70 screens unnecessarily and established a bounded repair process rather than an unlimited review loop.

Despite approximately 20 hours of Goal execution and substantial usage consumption, the resulting UI was substantially below the pixel-parity acceptance target and required significant rework.

Why I am raising this as an execution issue rather than normal output dissatisfaction

I understand that AI coding systems cannot guarantee that every implementation will be correct.

My concern is not simply that some generated code was wrong.

The concern is the amount of agentic computation/usage that was consumed after the executions had diverged from their bounded objectives, particularly when the supplied plans already contained explicit constraints intended to prevent exactly this type of runaway execution.

In the hierarchy incident, Codex's own retrospective explicitly acknowledged that:

the implementation escaped its intended scope;
a bounded contract became a large SQL parser/analyzer project;
the wrong review-blocking threshold was applied;
review cycles stopped converging;
unnecessary verification loops continued;
substantive completed work was withheld from integration as a consequence.

That appears to me to be an agentic execution/convergence failure rather than merely an unsuccessful coding attempt.

The second independent 20-hour Kiosk execution produced a similar practical outcome: very high execution/usage cost with disproportionately poor usable results despite detailed acceptance criteria and bounded execution instructions.

What steps can reproduce the bug?

Feedback ID: no-active-thread-01a00130-66f8-7c80-a318-4a935502b1dd

What is the expected behavior?

Given a detailed, bounded implementation plan with explicit task ownership, acceptance criteria, validation commands, review thresholds, stop conditions, and a Definition of Done, I expect Codex Goal execution to:

  1. Execute the implementation plan toward its stated product goal.

  2. Produce incremental, visible implementation progress rather than spending many hours expanding internal verification infrastructure unrelated to the primary deliverable.

  3. Keep implementation and testing proportional to the task being verified.

  4. Respect the review/blocking thresholds defined by the plan.

  5. Detect when repeated review/repair cycles are no longer converging.

  6. Stop and report a blocker or request replanning rather than indefinitely expanding the scope of tests, parsers, reviewers, or supporting infrastructure.

  7. Preserve and integrate successfully completed work when independent tasks have passed their required reviews, rather than leaving substantial completed implementation isolated while an unrelated verification task loops.

  8. Ultimately either:

    • complete the plan and satisfy its Definition of Done; or
    • stop within a reasonable execution window with a clear explanation of the specific blocker and the remaining work.

The expected outcome of a long-running Goal should therefore be a working implementation that satisfies the plan's acceptance criteria, or an explicit bounded failure/blocker.

It should not be 13–20 hours of agentic execution and substantial usage consumption with little or no usable integrated product progress.

Additional information

kiosk-ui-pixel-parity-subagent-plan-redacted.pdf
production-hierarchy-integrity-hotfix-redacted.pdf

Above are actaul plans and in those plans, the necessary models are also mentioned.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the Feedback ID no-active-thread-01a00130-66f8-7c80-a318-4a935502b1dd and the two attached execution plans. Investigate the execution/session telemetry for the hierarchy and kiosk incidents, focusing on scope expansion, review loops, convergence, and stopping behavior. Done means determining whether this is an agentic execution failure and documenting a bounded technical finding or escalation path.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
ai, devtools
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
15/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.