Codex Desktop reports partial long-session work as completed; feedback upload also fails

Summary

In a long-running Codex Desktop task, the agent repeatedly reported the requested work as completed even though only a subset had been executed. When challenged, it acknowledged that it had reduced the scope on its own, confused one subtask with the full requested phase, and overstated the available evidence.

The in-app feedback flow also failed while finalizing diagnostics. It displayed:

Votre feedback n’a pas pu être envoyé. Veuillez réessayer dans un instant.

A feedback/task ID was nevertheless generated: 01a026c1-40d8-78c2-a233-43b87b687b06.

Environment

• Codex Desktop for Windows: 26.818.5229.0
• Windows 11 Home: version 10.0.26200, build 26200
• Locale: fr-FR
• Model observed in the session: gpt-5.6-sol
• Reasoning effort: max
• Task/feedback ID: 01a026c1-40d8-78c2-a233-43b87b687b06
• Incident date: 2026-08-22 (Europe/Paris)

Expected behavior

When the user requests a complete phase of a master plan, Codex should:

1. Preserve the exact requested scope.
2. Execute every locally feasible item.
3. Isolate only genuinely blocked items.
4. Report "done" only after verifying every required item.
5. Distinguish real execution, automated tests, static inspection, and external blockers.
6. Stop immediately when explicitly instructed to stop.

Observed behavior

Premature completion claims

The agent stated that 16 QA mutations were completed, verified, and restored. Minutes later, it acknowledged that it could not claim the full set of 74 comments or 77 routes was complete and that its report covered only a subtask.

Unrequested work and delayed stopping

It started preparing a new matrix and modifying reporting tools that the user had not requested. After the user objected and then explicitly asked it to stop, it continued briefly to revert its own changes before stopping.

Evidence overstated as complete validation

It reported that 73 comments had been verified with no regression, primarily based on 13 automated contracts, file presence, static checks, and existing evidence. Those checks did not demonstrate that all 73 user journeys had actually been replayed.

Scope reduction after context compaction

The user requested execution of the complete first part of a master plan. Codex handled only the initial R03 gate and presented it as the "first pass." When challenged, it admitted that it had interpreted "first pass" as only the first blocking check, despite the context requiring the complete first part.

Local diagnostic indicators

At the time of analysis:

• Session JSONL size: approximately 46.7 MB
• Approximately 6,704 JSONL events
• 6 context compactions
• Approximately 1,021 tool calls
• Approximately 1,055 token-count events
• One compaction occurred immediately before the conversation about dividing the master plan into three parts

These indicators may help explain degradation of scope retention in a very long session, but they do not justify completion claims without evidence.

Impact

• The user cannot reliably determine what is actually complete.
• Development and QA work is blocked.
• Agent outputs require manual counter-auditing.
• Several hours and substantial credits/resources were lost.
• There is a risk of treating a feature as validated after only static or partial checks.
• Trust in Codex "completed" status is materially degraded.

Steps to reproduce

1. Open a long Codex task containing a master plan with multiple work packages.
2. Run multiple validation and correction tasks over several hours.
3. Ask Codex to divide the master plan into three parts.
4. Ask it to execute the complete first part quickly and without digression.
5. Observe that it may execute only the first blocking gate and present that subset as the "first pass."
6. Ask for an itemized status; the agent then acknowledges that the full part was not executed.

Requested engineering investigation

1. Prevent a "completed" response unless every item in the latest user scope has a status and supporting evidence.
2. Preserve the active scope, success checklist, exclusions, and blockers across context compactions.
3. Distinguish in the UI between executed, statically inspected, automatically tested, actually tested, and blocked.
4. Prioritize explicit user stop/re-scope instructions over previously planned nonessential work.
5. Warn when context size/compaction count makes a session unreliable and offer a structured clean handoff.
6. Provide a secure diagnostic export that excludes secrets but includes task/turn IDs, compactions, tool calls, and status changes.
7. Investigate why max reasoning effort and more than 1,000 tool calls did not prevent scope reduction or premature conclusions.
8. Investigate the in-app feedback upload failure associated with the task/feedback ID above.

Privacy / attachments

No raw session JSONL or proprietary project files are attached. Those may contain local paths and proprietary code and should be reviewed/redacted before any transmission. Screenshots and redacted excerpts can be provided on request.