Topic: Cursor AI chat export
Cursor AI Chat Export — What's Stored, What's Lost, and How to Capture Decisions
Cursor is the IDE of choice for a growing share of senior engineers. Its AI chat panel runs on Claude and GPT-4o and sits directly in the environment where architectural decisions get implemented. But Cursor has no conversation export, no history sync, and no data portability path. When you work through a significant architecture decision in Cursor Chat and close the panel, that reasoning is effectively gone. This page explains why — and what to do instead.
TL;DR
Cursor AI has no export for conversation history and no GDPR path that returns transcripts. Chat requests are routed through the Claude and OpenAI APIs as stateless calls — Anysphere does not store conversations server-side. Some conversation fragments exist in a local SQLite database in your application data directory, but the schema is an internal implementation detail that changes between versions and is not human-readable. The practical solution: use Claude.ai or ChatGPT for architecture deliberation (same models, permanent export-backed history), use Cursor for implementation tasks where the conversation is disposable.
Cursor's three AI surfaces — different persistence models
Cursor surfaces AI assistance through three distinct interfaces, each with a different storage model:
Cursor Chat (Cmd+L / Ctrl+L)
The full conversation panel in the sidebar, the primary place where engineers work through multi-turn deliberations. Conversations appear to persist locally during a session and across restarts within the same workspace — you can scroll back to earlier messages while Cursor is open. But this persistence is the VS Code extension's local state cache, not a server-side history. When the extension clears its state, the conversation is gone. There is no Settings page that shows "your last 100 Cursor Chat conversations" the way Claude.ai's sidebar shows conversation history. There is no export button. The conversation is ephemeral by architectural design.
Cursor Composer (Cmd+Shift+I)
The multi-file edit mode where Cursor proposes diffs across several files simultaneously. Composer sessions are even more ephemeral than Chat — the workspace state tracks the current Composer session but not a navigable history of previous ones. Engineers who use Composer for large refactors driven by a decision discussion lose the discussion context when the Composer session is closed.
Inline completions (Tab)
Single-line and multi-line completions triggered by cursor position. These are stateless by design — there is no "conversation" to export, and the completion context is discarded after the insertion. No storage, no recovery path, no decisions to capture.
Of the three, Cursor Chat is the only surface where engineers have extended deliberations that might contain architecture-quality decision reasoning. The rest of this page focuses on Cursor Chat.
Why Cursor cannot store conversation history
The architecture of Cursor Chat is fundamentally different from the architecture of ChatGPT or Claude.ai, and this difference explains the export gap.
ChatGPT and Claude.ai are stateful server-side products. When you send a message, the platform stores your message, the model's response, and the conversation thread on Anthropic's or OpenAI's servers. The next time you open the app, the same conversation is there because it lives in a database on their servers. The export button works because all your conversations exist in that database and can be dumped as a JSON file.
Cursor is a VS Code fork that makes API calls on your behalf. When you send a message in Cursor Chat, Cursor takes your message, appends the recent conversation context from its local state cache, sends the full messages array to the Claude API or OpenAI API, and receives a response. The API call is stateless — neither Anthropic nor OpenAI stores Cursor conversations as a retrievable conversation object (the same pattern as the Claude API and OpenAI Playground which have the same export gap). Anysphere (the company behind Cursor) acts as an API intermediary; they route the request but do not maintain a server-side conversation store.
The result: there is no server for Cursor to query when you click "export conversation history" — because that server does not exist in Cursor's architecture. The conversation context that makes subsequent turns coherent exists only in the local application state, not in a queryable history database on anyone's servers.
What is stored locally — and how to find it
Cursor does write some conversation data to your local filesystem as part of the VS Code extension state. The location depends on your operating system:
| OS | Path | Relevant file |
|---|---|---|
| Linux | ~/.config/Cursor/User/workspaceStorage/ |
{workspace-hash}/state.vscdb |
| macOS | ~/Library/Application Support/Cursor/User/workspaceStorage/ |
{workspace-hash}/state.vscdb |
| Windows | %APPDATA%\Cursor\User\workspaceStorage\ |
{workspace-hash}\state.vscdb |
The {workspace-hash} is a hash of the workspace folder path. To find the correct hash for a specific project folder, you can list the workspaceStorage directory and check the modification times, or compute the hash from the folder path using the VS Code workspace hashing algorithm (documented in the VS Code source but not officially published by Cursor).
The state.vscdb file is a SQLite database. You can inspect it with:
sqlite3 ~/.config/Cursor/User/workspaceStorage/{hash}/state.vscdb \
".tables"
The tables you find depend on which Cursor version you are running and what extensions are installed — there is no stable schema. Some Cursor versions store conversation fragments in an ItemTable table with a key-value structure where some keys contain JSON-serialized conversation state. To search for conversation content:
sqlite3 ~/.config/Cursor/User/workspaceStorage/{hash}/state.vscdb \
"SELECT key, substr(value, 1, 200) FROM ItemTable WHERE key LIKE '%cursor%' OR key LIKE '%chat%';"
The output is often fragmented JSON with encoded keys. Recovering a readable conversation transcript from this raw data requires writing a custom parser for the specific Cursor version's state format — this is forensic work, not a supported export path.
Important caveats about local storage forensics
- The schema changes between Cursor versions without notice. A script that extracts conversation history from Cursor 0.40 may produce nothing from Cursor 0.43. There is no public schema documentation for the state.vscdb contents.
- The local state is a cache, not an archive. Cursor clears extension state under various conditions (extension reinstall, workspace storage quota exceeded, manual Cursor reset, OS-level app data cleanup). The local state is less durable than a server-side conversation store.
- VS Code Settings Sync does NOT sync workspace storage. If you enable VS Code Settings Sync (which Cursor supports), it syncs your extensions, keybindings, and settings but not the workspace storage SQLite databases where conversation fragments live. Installing Cursor on a new machine gives you zero conversation history from your old machine.
What a GDPR data request returns
Cursor's privacy page describes a data deletion request path for EU/UK users. Submitting a GDPR data request to Anysphere returns:
- Account metadata: name, email address, account creation date, subscription status
- Billing history (plan changes, payment dates)
- Settings and preferences that Cursor stores server-side (not local settings)
It does not return:
- Conversation transcripts (Cursor Chat sessions)
- Composer sessions or diff histories
- Codebase index metadata (the Cursor codebase indexing feature syncs some code structure metadata to Anysphere's servers — GDPR responses do not include this in a human-readable format)
The absence of conversation transcripts in GDPR responses is structurally consistent with Cursor's architecture: if Anysphere does not store conversations server-side after the API call completes, there is nothing for them to return. This is different from ChatGPT and Claude.ai, where GDPR data requests do return conversation transcripts (though often in a less structured format than the standard data export).
AI IDE chat export comparison
| Platform | Conversation stored server-side? | Native export? | GDPR returns transcripts? | Local storage? | Decision-capture path |
|---|---|---|---|---|---|
| Cursor Chat | No — API-routed, stateless | No | No | Partial — SQLite state.vscdb, unstable schema | Redirect deliberation to Claude.ai or ChatGPT |
| GitHub Copilot Chat | No — same API-routed architecture | No | No — account metadata only | Partial — VS Code workspace storage (same pattern as Cursor) | Same redirect approach; see GitHub Copilot Chat export |
| Windsurf (Codeium) | Partial — Codeium stores some session metadata | No | No — account metadata only | Yes — VS Code extension state (similar to Cursor) | Same redirect approach; no native export available |
| Claude.ai (web) | Yes — full conversation store on Anthropic's servers | Yes — Settings → Account → Export Data → conversations.json | Yes — transcripts included in GDPR export | n/a (server-side product) | Use Claude.ai directly; run WhyChose extractor on conversations.json |
| ChatGPT (web) | Yes — full conversation store on OpenAI's servers | Yes — Settings → Data Controls → Export Data → conversations.json | Yes — transcripts included in GDPR export | n/a (server-side product) | Use ChatGPT directly; run WhyChose extractor on conversations.json |
| Zed AI | No — API-routed, stateless (same architecture as Cursor) | No | No | Partial — local assistant panel state | Same redirect approach |
The common pattern across AI IDE chat tools (Cursor, GitHub Copilot, Windsurf, Zed AI) is the same: they are VS Code forks or extensions that route AI requests through APIs, not products that maintain a server-side conversation store. The export gap is architectural, not a missing feature that will ship in the next release. ChatGPT and Claude.ai have durable exports because they are conversation-storage products first — the AI is what they sell, and the history is what keeps users returning. AI IDEs are code editors first — the conversation is a transient context window, not a recoverable asset.
The decision-capture strategy for Cursor users
If you use Cursor as your primary development environment, the practical strategy is to split AI interactions by durability requirement rather than trying to extract history from Cursor's local storage.
Use Cursor for: implementation-mode tasks
Cursor Chat and Cursor Composer are excellent for tasks where the conversation is disposable:
- Writing boilerplate or repetitive code across multiple files
- Debugging a specific error message with codebase context injected automatically
- Refactoring a function or module with awareness of its callers
- Generating tests for a specific function
- Explaining what an unfamiliar piece of code does
In all of these cases, the outcome is a code change. The conversation that produced it is not the important artifact — the code diff is. The conversation does not need to be recoverable because the decision (what to implement) is visible in the code, not buried in a chat transcript.
Use Claude.ai or ChatGPT for: architecture deliberation
Redirect conversations to a platform with durable exports when the conversation involves a decision that a future engineer will need to understand:
- Technology selection (database engine, message queue, auth provider)
- System design trade-offs (synchronous vs event-driven, monolith vs services)
- Pricing or business logic decisions with downstream implementation consequences
- Build-vs-buy decisions with multi-year implications
- Team process or tooling decisions (CI platform, deployment strategy)
Claude.ai and ChatGPT run the same underlying models as Cursor (Claude 3.5/3.7 and GPT-4o respectively). The quality of the deliberation is identical. The only difference is that the conversation is stored server-side and exportable — and that difference is decisive for architecture-quality decisions.
After the deliberation, export the conversation via Claude's data export and run the WhyChose extractor to extract the decision as a structured ADR record. Paste the extracted record into your /docs/decisions/ directory, open a PR, and the decision is in your canonical ADR archive — not buried in a Cursor chat panel that will be gone by the next workspace reset.
For decisions you've already made in Cursor
If you have already made a significant decision in Cursor and cannot recover the conversation, the most practical recovery approach is to reconstruct the reasoning from the artifacts that resulted from the decision:
- Read the git diff. The code change that implemented the decision often implies the alternatives that were considered. A
git log -pon the files that changed around the decision date surfaces the implementation choices directly. - Read the comments and commit messages. Engineers who use AI to deliberate often paste the AI's summary into a comment or commit message. Search the git log for keywords related to the decision.
- Reconstruct from the code structure. The choice of a specific library, pattern, or configuration implies the rejected alternatives. Write the ADR's Alternatives Considered section from the code structure — name the options that are NOT present in the codebase and describe why the chosen option was preferred over them.
- Ask the engineer who made the decision. If the decision is recent and the engineer is available, five minutes of conversation recovers more context than any forensic extraction from local storage.
Cursor Business and Enterprise: does the plan change the export story?
Cursor offers Business and Enterprise plans with additional privacy controls. The key differences relevant to conversation export are:
- Cursor Business: Prompts are not used for model training. The privacy improvement is about data retention policy at the model provider, not about creating a server-side conversation store that can be exported. Business plans do not add a conversation history feature or export capability.
- Cursor Enterprise: Single-tenant deployment options where the Cursor backend routes through your own VPC. In a self-hosted or VPC-routed Enterprise deployment, your IT infrastructure may be able to capture API traffic at the network level — but this is not an official export feature and requires deliberate infrastructure investment by your organization.
Neither plan adds the conversation history and export feature that ChatGPT and Claude.ai provide by default. The architectural constraint (API-routed, stateless calls) applies regardless of plan tier.
Why this matters for architecture decisions
The engineers who are most likely to make significant architecture decisions — staff engineers, senior engineers, engineering leads, solo-founder CTOs — are also the engineers most likely to use Cursor as their daily driver. Cursor's codebase-aware AI context makes it the most productive tool for implementation work. But the same engineers who make three to ten durable architecture decisions per week are making some of those decisions in Cursor Chat, and those decisions are not recoverable.
The new-CTO problem is particularly acute for decisions made in Cursor: when a new technical lead joins and asks "why did we choose this event-driven architecture instead of direct service calls?", the answer might be in a Cursor Chat session that closed six months ago. The code implements the choice, but the reasoning — the alternatives considered, the constraints that ruled out synchronous calls, the team's confidence level at the time — is gone.
The WhyChose extractor cannot recover decisions from Cursor Chat because there is no Cursor export format to process. What it can do is help you establish the discipline of routing architecture deliberation to Claude.ai or ChatGPT before opening Cursor to implement — so that the next export cycle surfaces those decisions as structured records before a new team member inherits the codebase without knowing why.
Related questions
Can you export Cursor AI chat history?
No — Cursor AI has no built-in export for conversation history and no data portability feature equivalent to ChatGPT's conversations.json or Claude's data export. Cursor routes AI chat requests through the Claude API and OpenAI API as stateless calls — Anysphere does not store conversation history server-side in a queryable way. Some conversation fragments are written to a local SQLite database in the user's application data directory, but this database is an internal implementation detail with a schema that changes between Cursor versions. There is no official export path, no GDPR request that returns conversation transcripts, and no Cursor settings page with a conversation history view.
Where does Cursor store chat history locally?
Some conversation data is written to the VS Code extension's local workspace storage. The path is ~/.config/Cursor/User/workspaceStorage/{workspace-hash}/state.vscdb on Linux, ~/Library/Application Support/Cursor/User/workspaceStorage/{workspace-hash}/state.vscdb on macOS, and %APPDATA%\Cursor\User\workspaceStorage\{workspace-hash}\state.vscdb on Windows. The workspace hash is computed from the workspace folder path. The state.vscdb file is a SQLite database that may contain partial conversation fragments, but the schema is an internal implementation detail that changes between Cursor versions without notice. VS Code Settings Sync does NOT sync workspace storage, so installing Cursor on a new machine gives you no conversation history from the old machine.
Does a GDPR data request return Cursor chat transcripts?
No. A GDPR data request to Anysphere returns account metadata (name, email, subscription details, billing history) but not conversation transcripts. Cursor's architecture routes chat requests through the Claude and OpenAI APIs as stateless calls — Anysphere does not maintain a server-side conversation store that could be returned in a GDPR request. This is structurally different from ChatGPT and Claude.ai, where GDPR requests do return conversation transcripts because those platforms store conversations server-side by design.
What's the best way to capture decisions made in Cursor?
Use Claude.ai or ChatGPT for architecture deliberation instead of Cursor Chat when the conversation involves a decision you will need to recover later. Both platforms store conversation history server-side, provide a native data export (Claude via Settings → Account → Export Data; ChatGPT via Settings → Data Controls → Export Data), and are compatible with the WhyChose extractor for structured decision extraction. Use Cursor for implementation-mode tasks — writing and editing code where the conversation is disposable. For decisions already made in Cursor, reconstruct from the code diff, git log, and direct conversation with the engineer who made the call.
Further reading
- GitHub Copilot Chat export — why there isn't one, and where your history actually lives — GitHub Copilot Chat has the same architectural pattern as Cursor: VS Code extension, API-routed requests, no server-side conversation store. The local storage path is different (VS Code extension storage rather than Cursor's separate data directory) but the fundamental export gap is identical. The disambiguation between GitHub Copilot Chat (the IDE chat panel), GitHub Copilot inline suggestions, github.com Copilot, and Copilot Workspace is particularly useful for enterprise teams trying to understand their AI decision-capture exposure across multiple Copilot surfaces.
- Can you export Claude API conversations? No — and here's why — the same architectural explanation applied to the Anthropic Messages API directly. The API is stateless; each request includes the full messages array and the server returns a response without persisting the conversation. Cursor uses the Claude API internally, so understanding the API's statelessness explains Cursor's export gap at the infrastructure level. The comparison table (Claude.ai vs Claude API vs Cursor) illustrates why the same underlying model can have dramatically different export stories depending on which interface you use.
- Can you export OpenAI Playground conversations? No — and here's why — the OpenAI-side parallel to the Claude API export page. OpenAI Playground Chat mode is a UI wrapper around the stateless
POST /v1/chat/completionsAPI. ChatGPT has a data export; Playground does not — because Playground is an API testing interface, not a conversation storage product. The same distinction applies to Cursor using the GPT-4o API vs a user using ChatGPT directly. - How to export your Claude conversations — the step-by-step guide for getting a conversations.json file from Claude.ai. The recommended destination for architecture deliberation that would otherwise happen in Cursor Chat. Settings → Account → Export Data → download the ZIP containing conversations.json.
- How to export your ChatGPT history (2026 guide) — the equivalent guide for ChatGPT. Settings → Data Controls → Export Data. Produces a conversations.json file compatible with the WhyChose extractor for structured decision extraction.
- Windsurf AI chat export — what Codeium stores, what's lost, and how to capture decisions — Windsurf (Codeium) has the same no-export outcome as Cursor, but a different underlying architecture: Codeium stores partial session metadata on its own infrastructure (unlike Cursor's pure API-routing model where Anysphere stores nothing server-side). The practical difference for engineers is zero — neither tool provides a user-accessible conversation archive. The Windsurf page covers the Codeium data model, Cascade vs Cursor Composer comparison, and the same redirect-to-Claude.ai/ChatGPT decision-capture strategy.
- Zed AI chat export — what Zed stores, what's lost, and how to capture decisions — Zed is architecturally the most distinct from Cursor of all AI IDEs: it's not a VS Code fork (written from scratch in Rust + GPUI), has no workspaceStorage equivalent, no state.vscdb SQLite file, and routes AI Panel requests directly from the Zed client to model provider APIs — bypassing any Zed Industries intermediary entirely. The most pass-through architecture in the cluster, yet the same zero-export outcome as Cursor.
- The open-source extractor — reads your Claude or ChatGPT conversations.json export and surfaces the architecture decisions inside as structured Nygard-compatible ADR records. The extractor is the tool that makes the redirect strategy concrete: use Claude.ai or ChatGPT for the deliberation, run the extractor quarterly to harvest the decision records, and route them into your ADR directory. Cursor decisions that happened before you adopted the redirect discipline are not recoverable by the extractor — there is no Cursor export format to process.