Codex Desktop attributes approval-wait time to tool execution and draws false performance conclusions

Environment

• Product: Codex Desktop for Windows
• Codex Desktop version: 26.803.10989.0
• Model in the confirmed occurrence: GPT-5.6 Sol
• Frequency: recurring intermittently during approximately the last one to two months

What issue are you seeing?

When an elevated tool call waits for manual approval and the approval is not given immediately, Codex can treat the entire approval-gated interval as evidence that the underlying command or request was slow.

This is not limited to a misleading elapsed-time display. After approval, the agent may immediately emit a progress message that invents a technical explanation for the apparent delay and then use that false finding to change its implementation or design plan.

In a confirmed occurrence, a small network query required manual approval. Approval was delayed while attention was elsewhere. Immediately after approval, the agent described the query as taking multiple minutes and treated that as evidence against using the query strategy by default. After correction, the agent acknowledged that the query itself completed in about 11 seconds and that the apparent multi-minute duration consisted largely of approval wait time. It then reversed the performance conclusion.

This indicates that the approval wait is not merely being shown as wall-clock time to the user. The model or its progress-update scheduling appears to lack a reliable distinction between:

• waiting for user approval;
• executing the tool; and
• processing the completed result.

What steps can reproduce the bug?

1. In Codex Desktop with manual approvals enabled, ask the agent to perform work that eventually requires an elevated command or network-backed tool call.
2. Use an operation whose actual execution time can be checked independently or is recorded in the tool result.
3. Leave the approval prompt unanswered for one or more minutes.
4. Approve the request.
5. Observe the first progress message after approval.
6. Compare any claimed command/request duration and diagnosis with the actual execution-only duration.

Observed intermittently:

• A progress message appears immediately after approval, consistent with a periodic progress threshold having elapsed while the task was waiting for the user.
• The agent says the command or request is taking unusually long, although it had not been executing for most of that interval.
• The agent supplies a plausible but unsupported technical cause for the delay.
• The false timing conclusion can be promoted into a real implementation decision, proposed workaround, or planned code change.

What is the expected behavior?

Approval waiting should be represented as a distinct lifecycle state in both agent-visible context and progress scheduling.

• End-to-end wall-clock time may still include the approval interval for user-facing task accounting, but it must not be presented to the model as execution duration without an explicit breakdown.
• Progress-message timers should pause while a tool is awaiting manual approval, or the resulting message should explicitly say that the task was waiting for approval rather than infer tool slowness.
• Tool completion context should expose execution-only duration separately from approval-wait duration.
• The agent should not make performance diagnoses or implementation changes from an approval-inflated elapsed time.

Additional information

This is related to #22312, which reported that /goal wall-clock accounting includes approval-wait time. That issue was closed as the wall-clock behavior being intentional. The problem here is different: approval wait is apparently misattributed by the agent as tool execution time and can affect technical reasoning and code/design decisions.

It is also distinct from reports where approval prompts are hidden, cancelled, or fail to resume. The prompt in this occurrence worked normally; the defect appeared in the interpretation of elapsed time after approval.

The example above is intentionally generalized. Raw task history is not attached because it contains unrelated workspace context, but the sequence and the approximately 11-second execution-only measurement were verified from the local Codex task history.