Does Deleting ChatGPT Chats Delete Your Data?

The May 13, 2025 preservation order (opens in new tab) explicitly covered user-requested deletions. The broad hold ended on September 26, 2025, with a limited historical collection still preserved. Users had clicked Delete. A court told OpenAI to keep the logs anyway.

Deleting a ChatGPT chat removes it from your history immediately. OpenAI normally schedules server deletion within 30 days. That's a long way from "gone."

Suppose you upload a severance agreement, ask whether the terms look reasonable, and delete the conversation when you're done. You've just handed over your compensation, your employer's name, and the details of a dispute. The chat disappears from the sidebar. The document can remain in Library. Authorized reviewers can access retained content. A court order can suspend deletion.

A useful answer about that agreement depends on what's in it. "Don't enter sensitive information" leaves me choosing between a vague answer and sharing the details I need help with. That's a pretty large catch for a tool I'm supposed to bring my problems to.

And the supposed escape routes need scrutiny too. An API key gets you different terms, but ordinary API requests can still leave logs. Even a gateway with zero data retention enabled can allow requests whose content is kept. Vercel's table (opens in new tab) labels OpenAI "ZDR with safety retention," and OpenAI's Safety Retention terms (opens in new tab) permit human review of flagged content. I'd want to know that before sending the severance agreement.

A court order can preserve deleted ChatGPT conversations

Your provider can be the one in court, and your private conversations can still get caught in the order. You don't have to be a party to the case.

That's what made the New York Times case so alarming. The May 2025 order required OpenAI to preserve output logs it would otherwise delete, explicitly including user-requested deletions. It reached across consumer ChatGPT and ordinary API accounts.

Picture someone using ChatGPT to work through a messy divorce, then deleting the exchange. A copyright dispute between a newspaper and an AI company is about as far from that person's problem as you can get. Yet a broad preservation order can keep their private conversation around because the provider is in litigation. The Delete button doesn't get a vote.

OpenAI's preservation notice (opens in new tab) says the order affected ChatGPT Free, Plus, Pro, and Team, along with API customers without a ZDR agreement. Enterprise, Edu, and API use through covered ZDR endpoints were excluded. An ordinary API key was not enough to avoid the hold.

Normal deletion resumed for new data. A limited collection from the hold remained preserved.

The October 2025 update says normal retention resumed on September 26, while limited historical data from April through September 2025 remained preserved. It excludes conversations originating in the EEA, Switzerland, and the UK from that continuing collection. Resuming deletion for new data didn't release all the data already caught by the hold.

Preservation wasn't the end of the story. A later demand sought a 20-million-conversation sample, and OpenAI's current case page (opens in new tab) says it complied after its appeal was ruled on. That was a separate sample, with de-identification and restrictions on access and use, not the entire collection of deleted chats and API logs. But the old reassurance that data wasn't being handed over "at this time" has expired.

I find the broader risk hard to shrug off. Another case can produce another order. The content available to be swept up will depend in part on what the provider still holds when that happens. A 30-day deletion policy gives me much less comfort once I've seen a court interrupt it.

Covered ZDR API requests escaped this particular hold because OpenAI didn't retain them. That's a practical reason to reduce storage at the outset, even though no provider is immune to legal demands.

Can OpenAI employees and contractors read your ChatGPT conversations?

Yes. OpenAI's consumer data policy (opens in new tab) allows authorized employees and service providers to access content for abuse or security investigations, support and troubleshooting, legal matters, and model improvement. Opting out of training removes that last purpose. The others remain.

OpenAI's warning is blunt: "Please do not enter sensitive information that you would not want reviewed or used."

This access is used in practice. On September 14, 2026, 404 Media reported (opens in new tab) that OpenAI was hiring hundreds of contractors under "Project Lily" to read user prompts, sometimes whole conversations, and assess the replies. The report was based on internal documents and prompts the outlet had seen. It said reviewers don't receive ChatGPT usernames, but sensitive personal details can survive the filtering.

OpenAI says access is restricted, logged, and governed by confidentiality obligations and staff training. I want those controls. I also want fewer people in a position to read my private work.

Imagine a reviewer encounters an unreleased acquisition plan, recognizes a company, and tells a friend. Or copies an interesting passage into the wrong place. Neither requires the whole database to leak. One person's bad judgment would be enough, and deleting the source a few weeks later wouldn't take the information back.

Thirty days is plenty of time for a person to read something. I'd weigh that access alongside the deletion deadline.

OpenAI's privacy filter doesn't guarantee anonymous conversations

OpenAI says it uses an internal Privacy Filter during training (opens in new tab), including on conversations whose users enabled model improvement. But its own description of the filter (opens in new tab) says it is "not an anonymization tool" and can miss unusual identifiers and ambiguous references.

Removing obvious identifiers doesn't guarantee that the remaining conversation is anonymous.

Suppose a filter removes your name but leaves "I'm the only pediatric surgeon at this small hospital, and I'm leaving after next month's merger." How anonymous is that to someone who knows the hospital?

Even perfect name removal wouldn't make an unreleased acquisition plan harmless to share. The plan itself is the secret. And the consumer access policy doesn't promise anonymization for every support, legal, or abuse review.

What ChatGPT's delete, archive, and training controls actually do

In a personal account, Settings > Data controls > Improve the model for everyone controls training on new conversations. It leaves your existing history alone. For a signed-in account, the choice follows you across devices (opens in new tab). You don't have to opt out separately in Chrome and on your iPhone.

ChatGPT's web settings with training off. Archive, delete, and export are separate actions below it.

The settings look like one privacy panel, but each button does a different job:

That 30-day server window comes from OpenAI's chat retention policy (opens in new tab). The Privacy Policy (opens in new tab) allows longer retention for legal, security, and safety needs. Content already de-identified and disconnected from your account for permitted model improvement is also excluded. Delete won't reverse training that already happened.

I'd use Temporary Chat for a task I don't need to revisit. It doesn't create or update memories, though personalized temporary chats can use existing memories and instructions. Save one and it becomes a regular chat. Either way, "temporary" still allows that safety copy for up to 30 days.

Then there's the thumbs-down button. Imagine ChatGPT botches an answer about your severance agreement and you report it. OpenAI says the associated conversation can be used for model improvement (opens in new tab) even after you've opted out. A complaint about a bad answer can put the private conversation back into consideration for training. I'd leave feedback off sensitive threads.

Codex can store chats remotely even when they don't sync across devices

A thread appears on your Mac but not your phone. It's easy to read that as "the chat only exists on my Mac." I wouldn't. A missing sync feature tells us very little about what OpenAI kept after processing the request.

OpenAI's Codex deletion guide (opens in new tab) says signed-in chats remain saved in the account until deletion. For Codex chats in the ChatGPT app, the instructions start with archiving, then deleting from Settings > Archived chats. The guide describes deleting a chat "locally" and then scheduling deletion from OpenAI's systems within 30 days.

"Locally" describes the immediate action. The same passage explicitly describes a later deletion from OpenAI's systems.

OpenAI is explicitly describing a server copy. It gives the same exceptions as ChatGPT: prior de-identification for permitted model improvement, and security, safety, or legal obligations.

There are local files too. OpenAI's troubleshooting documentation (opens in new tab) identifies session transcripts under ~/.codex/sessions, archived transcripts under ~/.codex/archived_sessions, and macOS application logs under ~/Library/Logs/com.openai.codex. The locations depend on configuration. If you've been pasting production code or customer data into tasks, those local transcripts deserve attention too.

Use the supported deletion control for an account thread. Deleting a local transcript by hand isn't a documented way to tell OpenAI to delete its copy. And OpenAI can't erase an export you made or a backup on another drive.

Codex also has a separate training control for environments. The ChatGPT training switch doesn't change Include environments, according to the model-improvement guide (opens in new tab). Signing into Codex with a personal ChatGPT plan uses that account's training rules; using an API key uses the API rules. The web settings expose both controls:

Codex's web settings have separate training and environment controls. Both are off here.

Do ChatGPT's privacy rules differ on the web, macOS, and iOS?

Using the same personal ChatGPT account through a native application doesn't move it onto the API's contract. The account's training choice applies across devices. OpenAI documents Chat and cloud Work history syncing across web, mobile, and desktop (opens in new tab), while Codex keeps a separate history. Local execution of a task doesn't mean all conversation data stays local.

The interfaces can hide different pieces of the cleanup. Library has its full interface on the web, with recent files and search on iOS and Android. If a file seems to have vanished on your phone, check Library on the web. On macOS, Record can turn a meeting into a transcript and canvas that outlive the original audio.

Then there's your own hardware. Browser caches, downloaded exports, application logs, and backups sit outside account history. Someone with access to your Mac doesn't need a copy from OpenAI if you've left a transcript on disk.

Deleting a ChatGPT conversation can leave uploaded files behind

Back to the severance agreement. The answer might summarize three clauses. The uploaded PDF could contain your salary, home address, signature, and the entire dispute. Delete the answer and leave the PDF in Library, and you've kept the more revealing half of the exchange.

Suppose someone later gets into the account. The chat you worried about is gone, but the original paperwork is still there to read. That's why I'd start cleanup with the files.

Library keeps its own copy. Its delete and recovery controls operate separately from the conversation.

Disconnecting Google Drive stops the next retrieval. A document already incorporated into a chat stays with that chat, as the Codex deletion guide explains. The original still lives in Drive too.

Personal ChatGPT accounts and API customers get different privacy terms

Paying for ChatGPT Plus or Pro doesn't buy the API's privacy terms. Both are personal subscriptions under the US consumer Terms of Use (opens in new tab), whether you use the website or a native application. Those terms let OpenAI use content to operate and improve the service. You have to opt out of training.

The consumer agreement allows model improvement and points you to an opt-out.

The Services Agreement (opens in new tab) covers API and business use. Section 4.2 limits use of customer content to providing the service, complying with law, enforcing policy, and preventing abuse. Developing or improving the service requires the customer's explicit agreement. For the API, no training is the starting point.

The API agreement makes the no-improvement promise part of the contract. It also permits processing for service delivery and abuse prevention.

But read the trigger on the deletion promise. Section 11.3's 30-day period starts after termination of the agreement, with legal and abuse exceptions. Your API account can stay open for years. This clause won't clean out last month's uploaded files for you. The Data Processing Addendum (opens in new tab) puts retention configuration and deletion during use on the customer.

The 30-day clock here starts when the agreement ends. Individual responses and files have their own storage rules.

The OpenAI API can retain abuse logs, responses, and uploaded files

A normal OpenAI API key gives you the no-training default. It doesn't give you Zero Data Retention. Standard abuse-monitoring logs can contain prompts and responses for up to 30 days, with legal or harm-prevention exceptions. OpenAI states this in its API data-controls documentation (opens in new tab).

No training by default, but content can still enter abuse-monitoring logs.

People can access stored API content too. OpenAI's API privacy FAQ (opens in new tab) permits authorized employees to access it for engineering support, abuse investigations, and legal compliance. Specialized contractors can review it for abuse and misuse under confidentiality and security obligations.

An application can create additional records through the API:

I'd ask the developer whether the client sets store=false and what happens to uploaded files. "Your history stays on your device" can be true while the same client creates retrievable responses at OpenAI. Keeping history in iCloud doesn't change that either.

OpenAI can cache prompt data for up to 24 hours

To avoid processing the same long prompt repeatedly, providers cache intermediate calculations. OpenAI describes these as encrypted key/value tensors in GPU-local storage. They aren't a second plain-text transcript, but they're derived from the prompt and can include the context of documents, images, and tool results.

You'd be forgiven for reading 30m as "gone in half an hour." OpenAI's newer setting specifies a minimum reuse period after the latest write or reuse. Keep reusing the prompt and you keep restarting that clock.

The word "minimum" matters. Reusing the prefix also restarts that period.

The prompt-caching guide (opens in new tab) describes older in-memory caches as typically lasting five to ten inactive minutes. Extended caching can last up to 24 hours. The current data policy (opens in new tab) also gives the newer cache state a 24-hour maximum, separately from the 30-minute minimum. Available controls depend on the model, and some models don't offer an in-memory-only choice.

You can't manually purge an individual request's cache. The model, feature, and agreement have to fit your retention needs before you send the content. Deleting the local chat afterward won't recall the calculations sitting on a GPU.

Why zero data retention can still come with a human-review exception

"Zero data retention" sounds wonderfully unambiguous. Then you meet "Safety Retention."

OpenAI's Safety Retention clause (opens in new tab) lets it make particular models ineligible for ZDR for particular customers when needed to investigate or prevent severe risks, after advance written notice. It can then keep flagged content and have people review it.

If I've chosen a route because I don't want people reading my prompts, that exception changes my decision. A gateway's ZDR switch needs to tell me which arrangement I'm getting. Protected ZDR with Private Safety Processing does exclude human access; Safety Retention permits it.

Getting ZDR directly from OpenAI requires approval and additional eligibility checks. An individual can't just buy API credits and turn it on. This is part of the appeal of gateways that make their provider agreements available to smaller customers.

With approved ZDR, prompt and response content is excluded from ordinary abuse logs, and supported Responses and Chat Completions requests treat store as false. OpenAI's ZDR explanation (opens in new tab) says covered content isn't available to its personnel for review.

Its newer ZDR with Private Safety Processing (opens in new tab) uses automated safety review in a protected computing environment that disables human access. Staff receive limited safety signals and operational metadata, not the underlying conversation. That remains the design even when a safety concern is flagged.

This arrangement explicitly excludes human access to the protected content.

Selected encrypted safety records still go into customer-controlled cloud storage with a 30-day expiry. The customer has to maintain that storage and its permissions. This takes an approved API arrangement and infrastructure, well beyond a personal ChatGPT setting.

The API data guide (opens in new tab) distinguishes the arrangements:

Changing a customer's model coverage to Private Retention with PSP also requires advance notice. That arrangement keeps encrypted content on OpenAI's infrastructure while excluding human review unless legally required.

These adjacent clauses make different promises about who can read stored content.

Images flagged as potential child sexual abuse material have another explicit exception: OpenAI retains them for manual review even with ZDR. Persistent features and outside tools also have their own rules. I'd want the provider's answer for the request I'm actually making.

When did OpenAI add human review to its ZDR policy?

OpenAI's API documentation explicitly added human review under Safety Retention in July 2026. The exception allowing it to retain flagged content had appeared that April.

The broader agreements had been changing too. OpenAI's November 2023 business terms (opens in new tab) promised deletion within 30 days after contract termination, unless the law required retention. By May 2025 (opens in new tab), the agreement also expressly allowed OpenAI to retain abusive content to protect its services or third parties from harm. That right was already there before the 2026 ZDR changes.

In the April 24-25, 2026 revision (opens in new tab), the API guide added Safety Retention. OpenAI could make specified models ineligible for ZDR for particular customers, with advance written notice, and retain content flagged for potential policy violations while investigating severe risks.

The July 8-9 revision (opens in new tab) added the words "and human review." It also broadened the model coverage and allowed retention to prevent severe risks as well as investigate them. Advance written notice remained. July also introduced Eyes Off, which retained content while excluding human review unless legally required.

Left: the earlier Safety Retention clause. Right: the July revision explicitly adds human review. The archive dates show when the wording changed, not when individual customers received notices.

By September 22 (opens in new tab), the guide added ZDR with Private Safety Processing and renamed Eyes Off to Private Retention with PSP. Those arrangements protect against human access. The separate Safety Retention clause stayed.

If I've built a private workflow around a ZDR approval, I now have to keep checking what it covers as models and policies change. If new terms allow people to read work I expected them to discard, I'd switch providers before sending more.

Gateways can make provider arrangements available to individuals. I've written about OpenRouter and Vercel AI Gateway for that reason. But their ZDR controls behave differently, and their own logging settings matter too.

OpenRouter's ZDR setting excludes requests served directly by OpenAI

OpenRouter makes a different call from Vercel. Its provider table (opens in new tab) marks OpenAI as retaining prompts for an unspecified period. Turn on ZDR for OpenAI models (opens in new tab), and OpenRouter excludes the first-party OpenAI endpoints. Azure remains eligible.

The setting below says exactly what happens. You can still use an OpenAI model, but the provider serving it changes. OpenRouter's public ZDR endpoint list (opens in new tab) also contains no first-party OpenAI route as of September 28, 2026.

OpenRouter excludes the first-party OpenAI route. Vercel's table, below, gives OpenAI a ZDR checkmark with a safety-retention exception. These controls make different promises.

Enable the OpenAI switch in account privacy settings or use provider.zdr=true on the request. The separate "All other models" switch doesn't cover the named model groups.

OpenRouter doesn't count in-memory caching as retention under that policy. Plugins such as web search also have separate terms. If those features matter to your workload, include them when choosing a route.

The gateway can keep a copy too. OpenRouter's optional Input & Output Logging saves content even when the upstream provider is eligible for ZDR.

Vercel's ZDR setting allows some requests with retention exceptions

Vercel AI Gateway offers gateway ZDR (opens in new tab) on Pro and Enterprise. It says the gateway itself doesn't retain prompts or outputs after the request. Upstream ZDR enforcement is an additional control.

Bring-your-own-key traffic is skipped by default because it uses your provider agreement. Marking a credential as ZDR-eligible tells Vercel about an arrangement you already have; it doesn't obtain that arrangement from OpenAI for you.

A direct personal API key doesn't acquire Vercel's provider agreement merely by passing through the gateway.

More surprising: requests using excluded models or features can still pass with ZDR enabled. Vercel also labels the OpenAI arrangement "ZDR with safety retention," bringing us back to the human-review clause. I want a privacy control to reject a request it can't protect. Here, a successful response can arrive even though a feature falls outside the promise.

Vercel says the request can succeed with ZDR enabled even when a feature has different retention rules.

Which settings can preserve data after you delete a chat?

OpenRouter's optional logging saves full prompts and responses

The control below offers to save the words you send and receive. It's off in this screenshot.

Enabling this creates a copy at OpenRouter, separate from the conversation in your client.

OpenRouter's Input & Output Logging (opens in new tab) saves the full content of future requests and replies. By default, it covers all your API keys; key filters can narrow that. Say you turn it on to debug a broken request on Friday. On Monday, you use the same keys to review a client's confidential proposal. Unless you've switched logging off or filtered those keys out, the debugging convenience can collect the proposal too.

OpenRouter specifies a minimum of three months, with longer retention possible unless you request deletion through support. Deleting the conversation in your chat client isn't that request. OpenRouter says these private logs aren't used for training. If the account is compromised while they're retained, though, "not used for training" won't protect the proposal.

Its separate Broadcast option sends data to an external observability service, adding another place to check. Upstream ZDR doesn't delete copies you asked a gateway or logging service to keep.

Deleting a ChatGPT conversation doesn't delete its saved memories

Tell ChatGPT about a health condition, let it save the detail as a memory, then delete the source chat. The memory can still be there. Imagine discovering that during a screen-shared conversation when the assistant brings up something you thought you'd removed.

The memory switch, summary, and saved memories are separate controls from deleting a chat.

In Settings > Personalization, review the memory summary and saved memories as well as your chats. OpenAI's Memory guide (opens in new tab) says to remove both a saved memory and the chats containing it. Turning off Memory leaves past chats in place. Where Don't mention this again is available, that changes future personalization without deleting the source. Even deleted saved memories can leave safety and debugging logs for up to 30 days.

Files have the same practical trap: deleting a conversation about a PDF can leave the PDF in Library. The file needs its own deletion.

Archiving a Codex chat keeps the conversation until you delete it

Archiving is useful for tidying the sidebar. It preserves the conversation, including connected-app content already used in it. Disconnecting the app stops future access but doesn't remove that existing conversation.

OpenAI's own illustrated guide: the delete control is inside Archived chats. Archive alone keeps the chat.

For Codex chats in the ChatGPT app, the documented workflow (opens in new tab) requires archiving first, then using Settings > Archived chats to delete. Stopping after the first step leaves the content stored. It's easy to get a tidy sidebar and mistake it for a cleanup.

Request logs can reveal account activity without storing the conversation

A Vercel gateway log (opens in new tab) can record when a request happened, which model and provider handled it, token counts, cost, and whether it succeeded. Even without the words, that can show when an account was active and how it used the service. OpenAI's Privacy Policy (opens in new tab) also describes IP addresses, device information, usage records, and records kept to document deletion requests. Removing a chat isn't a promise to erase every record that the account used the service.

A developer can create a much bigger problem by logging request bodies. Picture a team carefully choosing a ZDR provider, then piping every prompt into an error-reporting service to investigate bugs. The provider keeps its promise; the debugging system keeps the secrets. For a work tool, I'd ask where prompts, replies, and attachments end up when something fails.

How I'd protect sensitive information before sending it to AI

Deleting a conversation shouldn't require knowing which subsystem made which copy. The delete screen should tell me what remains and give me a way to remove it. Until products handle that properly, I'll judge their privacy by what they keep and who can read it.

For personal ChatGPT, I'd turn off model improvement, avoid feedback on private threads, and use Temporary Chat when I don't need history. When cleaning up, I'd check Library, saved memories, and projects along with the chat. I'd still assume authorized access is possible while content remains on the server.

For an API client, I'd check response storage and logging, choose the upstream provider, and use a ZDR route that covers my model and features. Gateways can make that possible without a direct negotiation with OpenAI. I'd reject a route whose exceptions defeat the reason I chose it.

And if a document simply cannot leave my hardware, I'd use an on-device model. A cloud provider has to receive enough of it to do the work. The time to make that decision is before upload.

Cumbersome lets you change AI providers without moving your chat history

I don't want years of conversations to become the reason I stay with a provider whose terms I no longer like. Models change. Policies change. At some point, I'll want to send the next question somewhere else.

That's part of why I built Cumbersome. On iPhone and Mac, it connects to the provider or gateway I choose, and I can switch models in the same conversation. My history syncs through my iCloud account. API keys stay in Keychain. Folding Sky doesn't run a prompt proxy or keep a conversation database.

The provider's retention rules still apply, including stored responses where used. For ZDR, I need an eligible provider arrangement; Cumbersome doesn't grant it to a normal API key. But I can choose where the next request goes without first packing up my conversation history and moving to another product. After reading all these exceptions, I want to keep that choice.