Approved plans do not reliably constrain Codex execution, causing silent scope expansion

What version of the Codex App are you using?

Observed across multiple recent Codex desktop app updates and with different models. The exact builds should be recoverable from the associated task logs.

What platform is your computer?

Windows desktop.

What issue are you seeing?

Reasonable, explicitly approved implementation plans do not reliably remain binding during execution.

The workflow is:

1. Discuss the goal and required features with Codex.
2. Ask for an implementation plan.
3. Review and adjust the plan.
4. Explicitly approve execution.
5. Observe Codex silently substitute a materially broader implementation without returning for approval.

In a representative case, the approved task was a small deterministic data-lineage correction:

• one row per extracted record;
• one decision column per tracked category;
• many-to-many matches allowed;
• accepted decisions deterministically produce observations;
• published results reconcile exactly to accepted observations;
• no accepted record may disappear silently.

The dataset contained only a few thousand records and a few dozen categories. The plan was estimated at approximately one hour.

Execution instead:

• reconstructed a complete workbook in memory rather than using the project's established incremental update path;
• recreated every sheet and added extensive formatting, inspection, reconciliation, and metadata structures;
• modified several publishing and update entry points;
• introduced broader validation infrastructure;
• changed an unrelated object-matching business rule;
• generated multiple numbered patch files to work around sandbox failures;
• rebuilt application artifacts;
• continued through three scratch attempts without delivering the approved feature.

The deterministic calculation itself completed quickly with modest memory. The workbook path behaved pathologically:

• existing workbook smaller than 1 MB;
• proposed matrix approximately 100,000 cells;
• capped exports exhausted a 512 MB heap;
• an earlier attempt exceeded 4 GB;
• no successful upper bound was established;
• no replacement workbook was produced.

The memory cap did not cause the problem; it exposed extreme amplification before the process consumed the machine again.

A fail-closed validation gate correctly prevented publication, but the approved task remained incomplete.

Sandbox and approval behaviour

Although the workspace was configured as writable, ordinary edits repeatedly failed because the Windows sandbox could not enforce the configured writable-root arrangement.

Codex responded with intermediate and numbered patch files, producing repeated approval prompts. Each prompt reasonably appeared to the user to be the final or penultimate mechanical permission needed to complete an already-approved task.

The prompts did not disclose that:

• the normal edit mechanism was malfunctioning;
• previous attempts had failed;
• implementation scope was expanding;
• further approvals would be required;
• elapsed time and implementation had materially diverged from the approved plan.

This makes filesystem approvals a misleading proxy for progress and creates approval fatigue.

Related Windows sandbox issues exist, but the central problem here is broader: sandbox failures, context compaction, delegation, and local improvisation can cause execution to abandon the approved plan without a renewed scope decision.

What steps can reproduce the bug?

1. In Codex Desktop, discuss a bounded code change that has an established project implementation pattern.
2. Ask Codex for a plan and explicitly approve that plan.
3. During execution, allow Codex to encounter a tool or sandbox constraint that makes the planned method inconvenient.
4. Observe whether Codex stops and reports the required deviation.
5. In affected tasks, Codex instead adopts broader implementation mechanisms, changes adjacent files or rules, and continues requesting approvals without clearly reporting that the approved plan is no longer being followed.
6. Compare the approved plan with the cumulative tool activity and resulting diff.

The exact domain is not essential. I have observed the broader plan-to-execution problem across multiple app versions and models.

What is the expected behavior?

The approved plan should remain the active execution contract.

Codex should:

1. Execute the approved approach using established project patterns.
2. Detect material divergence between planned and actual tool activity.
3. Stop and request renewed approval before changing architecture, business rules, or adjacent systems.
4. Surface failed attempts, cumulative scope, elapsed time, and likely remaining approvals.
5. Stop workaround chains when a configured writable workspace cannot be edited normally.
6. Distinguish approval for a filesystem action from approval for expanded implementation scope.
7. Preserve plan constraints through context compaction and delegated-agent work.
8. Treat extreme resource anomalies as stop conditions.
9. Provide a task-level diff against the state present when execution was approved.

The user should not need to write a multi-page PRD, enumerate every permitted file, or anticipate pathological implementation choices. Preserving the intent and boundaries of an approved plan is part of the agentic coding harness's job.

Actual behavior

Planning occurs at the appropriate level, but execution treats the approved plan as background context rather than a binding constraint. Tool failures and local improvisation can silently replace the approved method while the UI continues presenting individual approvals as routine progress.

User impact

• Minor bounded updates expand into multi-hour incomplete tasks.
• Original defects remain unresolved.
• Adjacent known issues are never reached.
• Workspaces require reconciliation before further changes can be trusted.
• Repeated approvals create the false impression that completion is imminent.
• Changing models or receiving app updates has not reliably resolved the behaviour.
• Trust in the plan-to-implementation pipeline is materially reduced.

Additional information

Private evidence is available if requested:

• full task transcript;
• screenshots of repeated approval prompts;
• scratch planning records;
• memory-exhaustion logs;
• unrelated business-rule validation failure;
• source and temporary-file inventory;
• artifact hashes;
• scale-test results.

Local paths and project-specific identifiers have intentionally been excluded from this public report.