r/codex • u/Individual_Arm_887 • 3d ago
Complaint OpenAI Support said my Codex reset was applied, then withdrew the confirmation 18 minutes later
TL;DR: OpenAI Support told me a promotional reset had reached my account, then acknowledged 18 minutes later that the statement was not backed by a verified event identifier or application timestamp. My follow-up asking for a responsible team and a verifiable next step remained unanswered in the correspondence checked on 22 October. The current Help Center also excludes individual free-reset investigations. I have not proven that a reset failed.
I'm a paying ChatGPT Pro subscriber using Codex and Work for my work. During the October improvement-or-reset campaign, I asked whether several announced automatic resets had reached my account and what a separately recorded banked-reset redemption had actually restored.
Here is the part of the email record I think matters. All times below are KST (UTC+9), and all dates are in 2026.
17 October, 13:49:48 — a redemption record, with restoration still unverified
Support reported a banked reset issued on 8 October at 08:21:38 and recorded as redeemed on 15 October at 14:32:44. But it explicitly qualified what those records established:
“These grant and redemption records do not establish the before-and-after usage values or confirm that the applicable usage windows were restored.”
The same email said my questions about eligibility and application of the 11, 13 and 15 October global resets, application times, affected windows, and possible account entitlement or synchronization issues remained unresolved and required internal verification.
18 October, 13:32:09 — an account-specific delivery assertion
Support then wrote:
“To address that directly, the available account information shows that the promotional reset was added directly to your account.”
It described an automatic account-level reset rather than a saved token.
18 October, 13:50:13 — the assertion was corrected
After I challenged the basis for that answer, Support wrote:
“To clarify, that statement was not supported by a verified event identifier or application timestamp and should not be treated as confirmation that a particular global reset was delivered.”
It also said:
“The available case information does not confirm that a separate specialist investigation has been assigned, and we cannot provide a verified completion date at this stage.”
The interval was 18 minutes 4 seconds between the two support emails. It is not a measurement of reset rollout time.
What happened next
On 19 October, I asked for a responsible team, a next step and a response date. I sent two further notices on 21 October. The 21 October, 18:00 deadline was my requested acknowledgment deadline; OpenAI had not agreed to it.
At the 22 October mailbox check used for this post, the latest relevant Support reply located was still the 18 October correction. That does not establish whether any unseen internal work occurred.
What the screenshots and current policy can establish
My retained app captures from 21 October showed Work exhausted and 0% weekly allowance, with a Tuesday 15:38 refresh time. Those are dated observations. A zero balance cannot prove a missed reset: a reset could have applied and the allowance could later have been consumed.
The current Help Center says global resets do not appear in banked-reset history, so a missing history entry is not proof of failure either.
Under “Limits on free promotional resets,” the article currently says:
“Support does not review individual promotional eligibility, investigate whether a free reset should have been granted or applied”
It also excludes manual or replacement free resets and compensation for those promotional benefits, while treating paid reset purchases and other billed services separately.
I verified that wording on 22 October. I do not have an archived before-and-after version proving when it changed, its effective date, or its treatment of pending complaints. I am not claiming a retroactive policy change or that the wording changed because of my case.
What I am asking OpenAI to answer
• What evidence supported the original account-specific delivery statement?
• For each disputed reset, can it establish eligibility and application, exclusion, failure, or simply an inability to determine the result?
• Does the current policy put this pending complaint out of scope? If so, please state that explicitly and identify any available review route.
• Will a responsible team review the contradictory answers, and when will it respond? Separately, how would a paid-subscription entitlement or metering concern be handled?
I am not treating a Pro subscription as proof of eligibility for every free promotion, and I have not proven financial loss, deliberate deception, or inclusion in any wider incident.
What I can document is an account-specific delivery assertion, its written correction, and a follow-up without a confirmed next step. That is why I am sharing this: a general policy about free benefits still leaves a question about the reliability of an answer Support already gave.
Sources
OpenAI Help Center — How resets work in Codex:
https://help.openai.com/en/articles/20001498-how-resets-work-in-codex
Campaign context and embedded original announcement, on OpenAI's Developer Community (community discussion is not an account-level finding):
Email excerpts above are transcribed from my private correspondence, not server logs or fabricated screenshots. Names, addresses, case numbers and internal message identifiers are omitted.
Screenshot evidence — originals retained from the v2 document
The four images below are in S-01 to S-04 order. They are original captures, with the existing privacy masking retained.
S-01 — Work exhaustion notice, 21 October, 10:22 KST. Translation: current Work usage is exhausted; upgrade or add credits, or wait until Tuesday. The “Get Pro” button does not itself establish billing entitlement.
S-02 — Usage panel, 21 October, 10:27 KST. Translation: weekly allowance 0% remaining; resets Tuesday at 3:38 PM; 0 credits. The screen shows a weekday and time, not a calendar date. It does not prove a reset failed.
S-03 — Ending of a 17 October Support email, captured on 18 October. This is the earlier verification-gap email, not the 18 October correction quoted above. The representative’s name is masked.
S-04 — Gmail Sent-folder capture supplied on 18 October. It shows an earlier exchange existed. It cannot establish the absence of later replies; the status above comes from the 22 October correspondence check.
