When Account Recovery Interrupts Engineering
An unresolved OpenAI access disruption, its impact on RC-01 development, and the continuity lessons we are carrying forward.
Published 2026-10-16 · Dated evidence, not a live status feed
What we observed
Between October 13 and 15, an OpenAI account-recovery problem interrupted the normal desktop workflow and delayed planned engineering work. Documenting that interruption belongs alongside our successful tests and creative progress.
On October 13, account recovery produced a 48-hour waiting notice. On October 15, an email said that waiting period had ended and provided the next recovery instruction. A later attempt was followed by another 48-hour notice. We have not established why the additional wait occurred.
Desktop sign-in attempts also produced physical security-key prompts. Screens showed prompts for both Apple and OpenAI at different points in the sign-in process. The phone session continued to work. These observations identify separate steps in the access path; they do not establish a common technical cause or prove that an account was compromised.
Support and evidence collection
Support engagement had not produced verified restoration of desktop access in the available record. An email containing video evidence was rejected because it exceeded the recipient’s message-size limit. An attachment-free resend was verified in sent mail. No subsequent bounce was found during the follow-up check late on October 15, but that alone does not establish receipt or review by support.
Project impact
The interruption prevented the normal desktop workflow from proceeding as planned. Mobile access allowed character design and animation-review work to continue, including Gigi’s development studies. That continuity helped preserve progress while desktop access remained unresolved. We have no verified evidence of project-file deletion from this incident.
What this teaches us
Recovery flows should explain waiting periods before they begin and make the next valid action unambiguous. When a new waiting notice follows a completion notice, users need a clear explanation of what happened and what to do next. Authentication prompts should make it easier to distinguish an identity-provider step from a service’s own verification step.
Support evidence collection also needs a dependable route for recordings, with attachment limits disclosed before submission. For RC-01, accessible copies of approved assets, documented recovery procedures, and clear separation between local files and account-dependent services are priorities. These are continuity requirements to verify, not a claim that every backup has already been qualified.
Resolution remains open
At this publication’s evidence cutoff, desktop recovery remains unresolved. The root cause is unknown, and we will record a resolution only when access is demonstrated. The same engineering standard applies here as it does to RC-01: preserve evidence, distinguish observations from conclusions, and verify the result.