Codex misinterpret instruction and used the banked reset without permission and authorization, while my usage was full. #41593

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   rate-limitsIssues related to rate limits, quotas, and token usage reportingIssues related to rate limits, quotas, and token usage reporting

   model-behaviorIssues related to behaviors exhibited by the modelIssues related to behaviors exhibited by the model

   on Aug 30, 2026
2. github-actions commented on Aug 30, 2026

   

   github-actionsBot

   on Aug 30, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Agent in goal modus automatically using banked reset #41502

   Powered by Codex Action
3. GGBondBlueWhale commented on Aug 30, 2026

   

   GGBondBlueWhale

   on Aug 30, 2026

   More actions

   I got the same issue!
4. wangzhuoyuan92-afk commented on Sep 6, 2026

   

   wangzhuoyuan92-afk

   on Sep 6, 2026

   More actions

   Another reproducible incident occurred on Windows with ChatGPT Plus on September 6, 2026 (GMT+8):

   1. The user manually redeemed one full usage reset.
   2. The assistant then misinterpreted the Chinese word “继续” (“continue”) as authorization to redeem another reset, although the user intended only to continue the running task.
   3. The user interrupted the tool call after approximately 2.4 seconds, but the server-side redemption still completed.
   4. An idempotent status check using the same request key returned alreadyRedeemed. The reset inventory was then zero, meaning two resets had been consumed in total.

   Expected behavior: redeeming a banked reset should require explicit, unambiguous confirmation that names the reset action. If the user interrupts a pending redemption, the interface should either prevent the redemption or clearly warn that the server-side action may already have completed.

   No account identifiers, task identifiers, project data, local paths, or credentials are included in this report.
5. sitrucp commented on Sep 6, 2026

   

   sitrucp

   on Sep 6, 2026 – with ChatGPT Codex Connector

   More actions

   Additional independent reproduction: “usage reset continue” consumed a second banked reset

   I encountered the same underlying authorization failure on September 5, 2026 using Codex Desktop for Windows on a Personal ChatGPT Pro account. The model recorded during the incident was gpt-6-astra.

   Verified sequence

   1. My Codex usage had run out, and I manually redeemed one banked reset myself in Settings → Usage.

   2. I returned to the project chat and typed exactly:

      usage reset continue

      I meant: the usage reset has been completed; continue the work.

   3. The assistant misinterpreted that as authorization to consume another banked reset and replied:

      “I’ll apply a usage reset and continue.”

   4. The assistant then invoked the reset-consumption operation. At approximately 10:34:01 AM CDT, the call was made; at approximately 10:34:04 AM CDT, it returned outcome: "reset".

   5. This consumed a second banked reset, even though the first reset had just been applied and I observed over 90% usage allowance remaining afterward.

   6. After I explained that I had already reset usage manually, the assistant acknowledged the mistake:

      “You were telling me you’d already reset usage—not asking me to spend another credit. I misread that and redeemed one unnecessarily.”

   Expected behavior

   A banked reset is a finite account resource and should not be consumable based solely on model-inferred intent from ambiguous conversational text.

   At minimum, redemption should require an explicit, immediately preceding confirmation that specifically names the action, for example:

   “Use one of your banked resets now?”

   Ideally, the backend should require a user-confirmation event that the model cannot synthesize or bypass.

   A second safeguard also seems appropriate: if a reset was just applied and the relevant allowance is already largely or fully restored, an immediate second redemption should be rejected or require especially explicit confirmation.

   Related reports

   This appears to be the same underlying authorization/control issue also reported in #41502 and #41801.

   I have provided the exact conversation/session identifier and redemption idempotency key privately to OpenAI Support and am intentionally not posting those account-tracing identifiers publicly.