Why I Am Done With OpenAI — and How Its Support System Failed Me

This is not a story about a chatbot giving me a bad answer. It is not about an image coming out wrong or a model refusing a prompt. It is about trusting a paid production tool with real work, watching it collapse, and discovering that the company behind it had built a support process perfectly designed to document a failure without taking responsibility for it.

For days, the Codex desktop app on my Mac became nearly unusable. The local backend repeatedly disappeared. Chats failed to resume. The interface flashed messages such as “Codex app-server is not available.” The backend restarted, tried again, consumed resources, and was killed again.

The signal was SIGKILL: the operating system’s final answer to a process that will not or cannot stop normally.

I began troubleshooting on August 7. I reinstalled the app. I restarted the Mac. I reset the local desktop profile while preserving a backup. I tested an older desktop build. I checked disk space, memory pressure, system processes, launch agents, logs, network behavior, Remote Control, plugins, third-party software, and whether another local process was killing Codex. I compared different bundled app-server versions. I followed false leads because the application offered no useful recovery path and Support offered no engineer.

At one point, the investigation found another real defect: OpenAI’s remote configuration enabled a feature called thread_tools, while the bundled runtime logged unknown feature key in config: thread_tools. The desktop app was running a backend identified as 0.147.0-alpha.6.6. In other words, a consumer-facing paid product was bundling software literally labeled alpha while receiving remote feature configuration it did not fully understand.

That was serious. But it was not the end of the story.

The 71 GB Chat

The decisive discovery was one local Codex conversation file:

76,013,248,054 bytes. Approximately 71 GB. One chat.

When the desktop app attempted to resume that conversation, the Codex process grew to approximately 46 GB in memory. The macOS unified log recorded the operating system killing the largest compressed process:

memorystatus: killing largest compressed process codex ... 46052 MB

The cycle was brutally simple:

App-server starts → oversized thread resumes → memory grows rapidly → macOS kills Codex → connection drops → app-server restarts.

I moved that single session file outside the active Codex sessions directory. The repeated memory-pressure, SIGKILL, and connection-failure loop stopped immediately. The rest of the local state remained unchanged.

I had found the practical cause and fixed the problem myself.

The app should never have allowed one session to grow to 71 GB without warning. It should not have tried to load enough of that session to consume tens of gigabytes of memory. It should have streamed the data, bounded the load, detected an anomalous file, stopped automatic resume, and offered a recovery or export path.

Instead, it repeatedly reopened the failure and let macOS kill it.

What It Cost

The chat was not disposable entertainment. It contained weeks of production history: editorial decisions, WordPress work, research, publication records, scheduled-task context, unfinished commitments, and the operational memory of projects I had been building.

Moving the file stopped the crashes, but it also removed normal access to that accumulated context. Scheduled tasks connected to old conversations became risky because they could attempt to return to the pathological thread. Some task definitions survived locally; other reasoning and working context had to be reconstructed from logs, files, and artifacts.

I also exhausted Codex usage during the period when the system was failing and useful work was not being completed. I asked OpenAI to review usage from July 21 through August 6 and to consider a credit or subscription adjustment for August 7 through 13. Support recorded the requests. It approved nothing.

The most offensive part was not merely the technical failure. Software fails. The offensive part was that I became the unpaid incident-response team for a company charging me to use the product.

Support Hell

OpenAI Support had the affected thread, the exact 71 GB session size, environment details, timestamps, screenshots, logs, the 46 GB memory event, repeated SIGKILL records, and the workaround that immediately stopped the failures.

Support explicitly acknowledged all of this.

It then said the technical escalation could not proceed without a Feedback ID from the affected session and a HAR file for a separate Remote Control authentication problem.

There was no Feedback ID from the original failure. The app had been busy failing. Reopening the quarantined session to obtain one risked restarting the same memory-pressure cycle. The requested HAR concerned a different Remote Control 403 error, not the 71 GB loading failure—and that separate error was no longer reproducible.

Support eventually clarified that it did not want me to recreate an unsafe condition. It also said it was “unable to proceed further through that escalation path” without the artifacts unavailable from that condition.

The logic was perfect in the most grotesque bureaucratic sense:

• Do not recreate the dangerous failure.
• We cannot investigate without evidence obtainable from the dangerous failure.
• Therefore, the failure is documented but cannot advance.

I did not need another courteous restatement of the checklist. I needed a human technical specialist to look at the evidence already collected. I needed Support to route a plainly documented product defect to the Codex desktop team. I needed someone with authority to say: yes, a 71 GB chat should not exist; yes, the app should not consume 46 GB trying to resume it; yes, we will investigate how that happened.

That conversation never happened.

The Public Confirmation

I publicly contacted Tibo, whose profile identifies him with Codex and ChatGPT at OpenAI. I received no direct response to my case.

Then I found the public exchange that Support had somehow failed to mention.

Token Gremlin posted:

“OpenAI is about to roll out a major performance optimization for extremely long chats.”

Tibo replied:

“We are.”

That exchange does not prove that the forthcoming optimization was prompted by my case. It does not prove that it will repair my quarantined 71 GB session. It does, however, confirm that OpenAI’s product team was actively working on performance for extremely long chats while Support was telling me that my extreme-long-chat failure could not move through its escalation process.

One side of the company publicly acknowledged the class of problem. The other side treated my evidence as procedurally unusable.

Support could have said one honest sentence:

We are aware of performance problems affecting extremely long chats and are preparing an optimization, but we cannot confirm whether it will resolve your specific case.

That would not have restored my work. It would not have refunded my subscription or returned the time I lost. But it would at least have been honest.

Instead, I got the performance of uncertainty from Support while the product team publicly confirmed that work was underway.

Alpha Software With Consumer Consequences

OpenAI has enormous power over the software delivered through its desktop ecosystem: bundled runtimes change, remote features arrive, and account-side configuration can alter behavior. The user experiences the result as one product, one subscription, and one company.

When that product includes an alpha-numbered backend, accepts server-delivered feature keys it may not recognize, permits a local conversation to reach 71 GB, and then enters a crash loop while trying to resume it, “move fast” stops sounding innovative. It starts sounding reckless.

From the outside, the arrangement began to look less like an accountable software company and more like a protection racket: the product creates the emergency, the customer performs the forensic work, Support demands evidence the broken product failed to preserve, and the subscription continues regardless.

I am not alleging a literal criminal conspiracy. I am describing how the relationship felt from the paying-customer side: power without accountability, automated authority without meaningful appeal, and a support structure that could record every fact while ensuring no responsible human had to answer for any of them.

That is serious.

What Accountability Would Look Like

The technical fixes are not mysterious:

• Bound local session growth.
• Stream long conversations instead of loading them wholesale.
• Detect anomalously large sessions before resume.
• Provide a recovery mode that opens without tools, images, or historical payloads.
• Allow users to export, compact, split, or archive a damaged conversation.
• Keep scheduled tasks from automatically returning to a pathological thread.
• Make remote feature configuration compatible with the bundled runtime before rollout.
• Preserve a diagnostic package when the app crashes, so escalation does not depend on evidence the crash prevented the user from collecting.

The support fixes are equally obvious:

• Give frontline agents a route to a technical human when a customer supplies reproducible logs and a working mitigation.
• Do not require a Feedback ID from a session that cannot safely be reopened.
• Do not combine unrelated diagnostic requirements into one escalation gate.
• Tell customers when the product team is already working on the affected class of problem.
• Review charges and usage when the company’s failure consumes paid access without delivering work.
• Close the loop after an update ships.

None of this requires artificial intelligence. It requires ordinary engineering discipline and ordinary corporate responsibility.

Why I Am Done

I no longer trust a chat as the sole repository of serious work. I no longer trust OpenAI Support to connect documented technical evidence with someone empowered to act on it. And I am no longer willing to spend my time debugging a paid product while the company hides behind an escalation package its own failure made impossible to complete.

I am moving the durable parts of my work into local files, repositories, manifests, backups, local agents, and models I can run or replace without asking permission. Chats can assist. They cannot remain the only place where the work exists.

OpenAI did not lose me because software failed once. It lost me because I diagnosed the failure, proved the failure, fixed the failure, and still could not get accountability from the company that shipped it.

My case was documented.

The application, alas, was not consulted.

Disclosure: This article is based on local Codex session records, macOS logs, preserved OpenAI Support correspondence, and public X posts. The public optimization announcement confirms work on extremely long-chat performance; it does not establish that my individual report caused the update or that the update will recover my quarantined session.