What version of Codex CLI is running?
codex-cli 0.130.0
What subscription do you have?
premium
Which model were you using?
gpt-5.5, but this is true for all of them so far
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What terminal emulator and version are you using (if applicable)?
PowerShell
What issue are you seeing?
I’m frustrated with how Codex usage is handled when the agent clearly fails at a mechanical task and then retries on its own.
For example, I had Codex attempt a file edit and it literally responded with:
“The file was not changed. I’m going to update the specific lines by line number range instead of doing a broad string match.”
So the system:
- knew the edit failed
- knew the strategy failed
- initiated its own retry
- then consumed more usage fixing its own mistake
That doesn’t feel fair from a user perspective. I understand retries consume compute, but if the agent can explicitly detect failed operations and autonomous recovery loops, it feels wrong for users to be charged/limited identically for those failures.
This is especially frustrating when the failure is not due to unclear instructions or changing requirements, but because the tool itself failed to perform the operation correctly.
I’d really like to see some kind of retry forgiveness or different handling for self-identified failed operations/recovery loops. Right now it creates the feeling that users are absorbing the cost of platform/tool instability.
What steps can reproduce the bug?
Uploaded thread: 019e028c-2536-7693-bb11-0fc7edd57637
What is the expected behavior?
When Codex detects that a file edit or patch operation failed and automatically retries using a different strategy, the retry/recovery work should not count against the user’s usage/limits.
If the system is capable of explicitly identifying failed operations (“The file was not changed”) and autonomously initiating corrective behavior, users should not be charged/limited for recovery work caused by platform/tool failure.
Additional information
This feedback is specifically about mechanical/tooling failures, not incorrect AI answers or ambiguous prompts.
The issue is not that failures happen. The issue is that failed operations and autonomous recovery attempts still count against user usage/limits, even when the failure was caused by the agent failing to correctly perform a file edit/patch operation and explicitly acknowledged by the system itself.
These retry/recovery loops happen consistently during normal daily use. Codex regularly acknowledges that an edit or patch operation failed and then retries automatically using a different strategy. The problem is not the retry itself — the problem is that users are still charged/limited for repeated recovery attempts initiated entirely by the agent.
In my case, Codex explicitly acknowledged that its edit strategy failed and then retried automatically using a different method. The retry was initiated by the agent itself, not by a new user request, unclear instructions, or changing requirements.
If the system is capable of identifying that an operation failed and autonomously deciding to retry it, users should not absorb the usage cost of recovery work caused by platform/tool failure.
What version of Codex CLI is running?
codex-cli 0.130.0
What subscription do you have?
premium
Which model were you using?
gpt-5.5, but this is true for all of them so far
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What terminal emulator and version are you using (if applicable)?
PowerShell
What issue are you seeing?
I’m frustrated with how Codex usage is handled when the agent clearly fails at a mechanical task and then retries on its own.
For example, I had Codex attempt a file edit and it literally responded with:
“The file was not changed. I’m going to update the specific lines by line number range instead of doing a broad string match.”
So the system:
That doesn’t feel fair from a user perspective. I understand retries consume compute, but if the agent can explicitly detect failed operations and autonomous recovery loops, it feels wrong for users to be charged/limited identically for those failures.
This is especially frustrating when the failure is not due to unclear instructions or changing requirements, but because the tool itself failed to perform the operation correctly.
I’d really like to see some kind of retry forgiveness or different handling for self-identified failed operations/recovery loops. Right now it creates the feeling that users are absorbing the cost of platform/tool instability.
What steps can reproduce the bug?
Uploaded thread: 019e028c-2536-7693-bb11-0fc7edd57637
What is the expected behavior?
When Codex detects that a file edit or patch operation failed and automatically retries using a different strategy, the retry/recovery work should not count against the user’s usage/limits.
If the system is capable of explicitly identifying failed operations (“The file was not changed”) and autonomously initiating corrective behavior, users should not be charged/limited for recovery work caused by platform/tool failure.
Additional information
This feedback is specifically about mechanical/tooling failures, not incorrect AI answers or ambiguous prompts.
The issue is not that failures happen. The issue is that failed operations and autonomous recovery attempts still count against user usage/limits, even when the failure was caused by the agent failing to correctly perform a file edit/patch operation and explicitly acknowledged by the system itself.
These retry/recovery loops happen consistently during normal daily use. Codex regularly acknowledges that an edit or patch operation failed and then retries automatically using a different strategy. The problem is not the retry itself — the problem is that users are still charged/limited for repeated recovery attempts initiated entirely by the agent.
In my case, Codex explicitly acknowledged that its edit strategy failed and then retried automatically using a different method. The retry was initiated by the agent itself, not by a new user request, unclear instructions, or changing requirements.
If the system is capable of identifying that an operation failed and autonomously deciding to retry it, users should not absorb the usage cost of recovery work caused by platform/tool failure.