ChatGPT Export: The Fix at Every Stage

John Rood··6 min read

The months of conversations beneath ChatGPT's saved-memory summary move through one official artifact, the data export. It runs on timers most people discover too late. The email can take up to seven days to arrive. The download link expires twenty-four hours after it does. Chats deleted before the request are not in the file and do not come back.

Those are only the first gates. Every stage after them has its own failure mode and its own fix, and knowing which stage you are in is most of the work. This is the map from export request to first recall. The commands live in the ChatGPT import documentation, and the walkthrough goes through selection and approval step by step.

The email can take a week

Request the export from Settings, then Data Controls, then Export Data. Then wait, because the wait is the first place a run dies. Nothing is broken on day three or day five, and a second request does not speed up the first. While one export is processing, the page may report that a request already exists. Check the inbox tied to the account, spam and promotions included, or the messages app if the account runs on a phone number. If seven days pass with nothing, that is the point to contact OpenAI support.

The wait is free preparation time. A supported Node install, a Memory Key that can write to your vault, and a test vault can all be ready before the email lands.

The link expires in a day

Download the archive as soon as the notification arrives and keep the file. The link is good for twenty-four hours, opens only while signed in to the account that requested it, and cannot be revived once it lapses. An expired link means a new export request through the same settings page or the Privacy Portal, and the portal is the route when signing in is the problem itself.

The archive deserves the same care as the account it came from, because it includes account data beyond the conversations. Keep the original file untouched as the reference copy for everything downstream.

Some accounts get no export button

Self-service export covers Free, Go, Plus, Pro, and eligible Edu workspaces. Business, Enterprise, and Healthcare workspaces are not included, so there the request goes to the workspace owner. Edu availability depends on role, workspace settings, and data residency.

One version of this trap is worth its own warning. When a personal workspace is being merged into a managed one, request, download, and inspect the export before the personal workspace is removed. After the removal, an older link may stop opening and a new request may not be possible at all. The file has to exist before the door closes.

Deleted chats never show up

Open the archive and compare it against memory. Chats deleted before the request cannot be restored by any export, because the data is gone at the source. The remainder can still be imported into a memory vault, which is a different job from keeping a browsable backup. If browsing is the whole goal, a local archive viewer is simpler and never touches a server. If recall is the goal, the import sits alongside the connection paths in the integrations directory.

Inspection runs before anything moves, with no network call and no vault write, and it reports what the archive holds: how many conversations it found, which messages are the kept version, what it will skip, and the date range everything covers. Side branches, tool and system messages, and non-text content get skipped and reported, never forced in. The counts from inspection and the receipt are the truth about what moved. The archive's size is not.

When the file will not inspect

Go back to the source. Download the export again while the link still works, or unzip it and point the importer at the extracted folder, or the conversations.json inside it. Renaming a different archive so it poses as an export will not get past inspection.

Nothing to import is usually a selection problem, not a broken file. Check the date boundaries and any excluded conversation IDs first. Date boundaries are read as UTC, so an edge can land earlier than local time suggests.

When the run will not finish

Before records move, prepare builds the exact selection and a current price quote, and approve binds the two. An approval that is refused is almost always a billing or authentication problem on the account. Fix that, prepare a fresh quote, and start the approval again.

Once a run is underway, interruptions are expected. Batches are resumable and idempotent. Keep the working folder, check status, and resume from the last committed batch; records that already went through replay without doubling up in storage or on the bill. If the run reports that the archive or the destination changed, put the original file back at the original path and the same authenticated vault before resuming, and prepare a new workspace only for a new selection.

The receipt is what to reconcile when the run ends. It counts what was stored, what came back as duplicates, what was skipped, and what failed. A clean finish with a failed count above zero is an unfinished import. Cancel is for stopping future batches. It leaves stored records where they are, and removal happens in the dashboard.

When recall comes back empty

The receipt checks out, and a new session still cannot answer from the archive. Four causes produce that, and they are cheap to tell apart.

The connector answers from a different vault than the import filled. An OAuth connection picks one vault when it is created and stays with that choice. The usual mismatch is a new personal vault on the connector against the project vault that holds the import. Run memory_status and compare the vault it names with the import destination.

The question never asked for a search. Recall in chat assistants is model-directed, so a wrong answer may mean no lookup happened. Request the search by name.

The index has not caught up yet. If the receipt is minutes old, search again before reimporting anything.

The answer is an improvisation. Ask for a detail you know is absent. If a fluent guess comes back for that one too, the model is filling gaps rather than reading the vault. A recall counts as proven when the search result shows the source.

Prove the pipeline once before trusting it

One synthetic fact in a test conversation, requested through an export that contains only that conversation, imported into a test vault, then recalled cold in a session with nothing copied over. A run whose counts reconcile and whose fact comes back with the search attached is a proven pipeline. The real archive is a rerun of a working process instead of a leap into one.

Create your MemoryRouter account, put one export through the whole pipeline, and confirm the cold recall before the rest of the history follows.