Topic: Zed AI chat export
Zed AI Chat Export — What Zed Stores, What's Lost, and How to Capture Decisions
Zed is the fastest-growing native code editor among Rust-ecosystem and performance-focused engineers, with a built-in AI Panel that can call Claude, GPT-4o, and Gemini directly. Its architecture is unlike Cursor and Windsurf — Zed is not a VS Code fork but a scratch-built Rust application with its own GPU-accelerated UI framework. But like every other AI IDE, Zed has no conversation history export for AI Panel sessions. When you close a Zed AI Panel thread that reasoned through a significant architecture call, that reasoning is gone. This page explains why — and what to do instead.
TL;DR
Zed's AI Panel routes requests directly from the Zed client to model provider APIs (Anthropic, OpenAI, Google) with no Zed Industries server in between. There is no server-side conversation archive, no export button, and no GDPR path that returns conversation transcripts. Zed is architecturally the most pass-through of all AI IDEs — but the user-facing export story is identical to Cursor and Windsurf: zero conversation export. The solution: use Claude.ai or ChatGPT for architecture deliberation — the same underlying models, permanently stored and exportable history — and use Zed's AI Panel for implementation-mode tasks where the conversation is disposable.
What makes Zed architecturally distinct from VS Code forks
Cursor, Windsurf, and GitHub Copilot Chat are all built on VS Code's codebase — they are VS Code forks (or VS Code extensions) that add AI capabilities to Microsoft's existing editor architecture. Zed is not. Zed was written from scratch in Rust using GPUI, Zed Industries' own GPU-accelerated UI framework, with no dependency on VS Code's codebase, extension API, or language service architecture.
The practical consequences for engineers who think about storage and export:
- Zed has no equivalent of VS Code's
workspaceStoragedirectory — the VS Code-specific SQLite files that contain partial conversation state for Cursor (state.vscdb) and Windsurf don't exist in Zed's storage model. - Zed's AI Panel state is held in memory for the duration of the editor session. There is no background persistence of conversation turns to a local database.
- Zed's extension model is different from VS Code's — Zed extensions are written in WebAssembly and communicate through Zed's own extension API, not VS Code's Language Server Protocol extension point. This means there is no VS Code-style extension that could intercept and log AI Panel traffic the way some VS Code extensions capture Copilot Chat output.
These distinctions matter for understanding the export gap. Cursor and Windsurf users sometimes recover partial conversation history from the local state.vscdb SQLite file — it's an unsupported path, but the file exists. Zed users don't have this fallback: there is no local SQLite file with AI Panel state. Once the session is closed, the conversation is not on disk anywhere.
Zed's three AI surfaces — what each stores
AI Panel (the multi-turn conversation surface)
The primary Zed AI surface and the one where architecture deliberation happens. The AI Panel is a sidebar panel in Zed that supports multi-turn conversations with Claude, GPT-4o, or Gemini (configurable via Zed settings). You can add file context by typing /file to include a specific file in the conversation, or /project to include relevant files from the project. The AI Panel supports conversation threads — you can start a new thread or continue an existing one within the same editor session.
Conversation threads persist within a Zed session but not across sessions. When you close Zed, the AI Panel history is gone. There is no conversation history view in Zed's settings, no export button, and no way to access past conversations from a different machine or after reinstalling Zed.
Inline completions (Zeta and cloud models)
Zed's inline completion surface uses either Zeta — Zed Industries' own fine-tuned code completion model, served from Zed's servers — or a configurable cloud model. Completions are stateless: each completion is triggered by the cursor position, the model returns a suggestion, the suggestion is accepted or rejected. There is no "conversation" to export and no persistent context beyond what the completion request includes. Usage telemetry (accepted/rejected completion counts) is sent to Zed for Zeta model improvement, and can be disabled in Zed settings.
Edit predictions (agentic mode)
Zed's edit prediction mode accepts multi-file edits suggested by the AI: the model proposes a set of file changes, and the engineer reviews and accepts or rejects them. This is analogous to Cursor Composer or Windsurf Cascade Write mode — an agentic surface for multi-file refactors. Like those surfaces, edit predictions have no conversation history persistence. The proposed diff is the artifact; the reasoning that produced it is not stored.
What Zed stores and where
What zed.dev stores server-side
- Account authentication: email address, GitHub OAuth identity (for users who signed up via GitHub), account creation date, subscription plan (Free / Pro)
- Billing and subscription data: payment history, current plan, Pro trial state
- Zeta completion telemetry: if telemetry is enabled (the default for Free plan users), Zed sends accepted/rejected completion counts and anonymized code snippets around accepted completions for Zeta model training. This is completion telemetry, not AI Panel conversation content.
- Usage statistics: aggregate editor usage counts — sessions, file types edited, Zed version — for product analytics
Zed Industries does not store AI Panel conversation transcripts. The model provider APIs (Anthropic, OpenAI, Google) receive the conversation messages that the Zed client sends them — but those messages go directly from the Zed client to the model provider endpoint without passing through a Zed Industries server. Zed Industries has no copy of these messages and no server-side conversation database to query.
What is stored locally
Zed's local configuration files are in OS-specific locations:
| OS | Path |
|---|---|
| Linux | ~/.config/zed/ |
| macOS | ~/Library/Application Support/Zed/ |
| Windows | %APPDATA%\Zed\ |
These directories contain Zed's settings file (settings.json), keymaps, themes, and extension configuration — not AI Panel conversation history. There is no workspaceStorage equivalent in Zed's local storage model because Zed's architecture does not use VS Code's storage abstractions. AI Panel conversation state is in-memory only and is not written to any file in these directories.
What a GDPR data request returns
A GDPR data access request to Zed Industries returns:
- Account metadata: email address, GitHub OAuth identity, account creation date, subscription status
- Billing history
- Aggregate usage statistics and Zeta completion telemetry (if telemetry was enabled)
It does not return:
- AI Panel conversation transcripts
- Edit prediction histories
- File context included in AI Panel conversations
The absence of transcript content in the GDPR response is structurally consistent with Zed's architecture: there is no server-side conversation database to query. The GDPR access request produces account-metadata-only output — the same category of response as Cursor and GitHub Copilot Chat GDPR requests, but for a different reason. Cursor routes through Anysphere servers (there are server-side request logs, but Anysphere doesn't surface those as conversation transcripts in GDPR responses). Zed doesn't have those request logs at all because the AI Panel traffic bypasses Zed's servers entirely.
The Zeta model — Zed's own inline completion system
Zeta is Zed Industries' fine-tuned code completion model, trained specifically for inline code suggestions. Zeta is distinct from the AI Panel in several important ways:
- Zeta is served from Zed Industries' own inference infrastructure — completions go to Zed's servers, not directly to a third-party model provider API
- Zeta receives code snippets (around the cursor) as context, not conversation turns
- Zeta completion telemetry is opt-in for Pro users and opt-out for Free users — the settings preference is at
Zed → Settings → telemetry - Zeta is used only for inline completions, not for the AI Panel. AI Panel requests go to Anthropic, OpenAI, or Google depending on your configured provider
The distinction matters for export purposes: Zeta completion context (the code snippets sent to Zed's servers for completion) is not the same as AI Panel conversation content. Even though Zeta completions do pass through Zed's servers, the completion context is not structured as a conversation and is not stored in a format that produces an exportable conversation transcript.
AI IDE chat export comparison
The export gap is consistent across all AI IDEs — but the architectural reasons differ:
| Platform | Architecture | Server-side conversation storage | Native export | GDPR transcripts? | Local conversation storage | Decision-capture path |
|---|---|---|---|---|---|---|
| Zed AI Panel | Direct client → provider API (no Zed intermediary) | None — Zed Industries never receives conversation content | No | No — account metadata only | In-memory only, no local file | Redirect deliberation to Claude.ai or ChatGPT |
| Cursor Chat | Client → Anysphere servers → provider API | No user-accessible archive — Anysphere logs requests but doesn't surface them | No | No — account metadata only | Partial — state.vscdb SQLite (unstable schema); see Cursor AI chat export | Redirect deliberation to Claude.ai or ChatGPT |
| Windsurf Cascade | Client → Codeium model infrastructure → provider API | Partial — Codeium session metadata, not full transcripts | No | No — account metadata only | VS Code extension state (workspaceStorage); see Windsurf AI export | Redirect deliberation to Claude.ai or ChatGPT |
| GitHub Copilot Chat | VS Code extension → GitHub API proxy → OpenAI API | Local only — not transmitted to GitHub servers | No | No — aggregate telemetry only | VS Code workspace storage (local device only); see GitHub Copilot Chat export | Manual copy-paste at session time |
| Claude.ai (web) | Browser → Anthropic servers | Yes — full conversation store on Anthropic's servers | Yes — Settings → Account → Export Data → conversations.json | Yes — transcripts included | n/a (server-side) | Run WhyChose extractor on conversations.json |
| ChatGPT (web) | Browser → OpenAI servers | Yes — full conversation store on OpenAI's servers | Yes — Settings → Data Controls → Export Data → conversations.json | Yes — transcripts included | n/a (server-side) | Run WhyChose extractor on conversations.json |
The pattern across all AI IDEs is consistent: code editors are implementation tools where the conversation is a transient context window, not a stored product. ChatGPT and Claude.ai are conversation-storage products where the chat history is the retention mechanism. The same underlying models (Claude 3.x, GPT-4o) produce completely different portability profiles depending on which product surface they are called through. Zed's direct-API-routing model makes this structural divide even starker than Cursor or Windsurf: Zed Industries is not in the conversation path at all.
The decision-capture strategy for Zed users
The strategy is the same as for Cursor and Windsurf users: separate AI interactions by durability requirement, not by which tool is open at the moment.
Use Zed's AI Panel for: implementation-mode tasks
Zed's AI Panel is excellent for tasks where the conversation is disposable — where the output is a code change and the reasoning behind the specific implementation choices doesn't need to outlive the session:
- Refactoring a function to a different pattern, with Zed's codebase context via
/project - Generating tests for an existing module with file context via
/file - Debugging a specific error with the relevant file included in the AI Panel context
- Implementing a feature whose design was already decided elsewhere
- Writing documentation for existing code
In these cases, the outcome is a code change. The conversation that produced the diff is not the important artifact — the diff is. You don't need to recover the reasoning.
Use Claude.ai or ChatGPT for: architecture deliberation
When the reasoning itself is the artifact — when a future engineer will need to understand not just what was built but why this approach was chosen over the alternatives — redirect the conversation to a platform with durable exports:
- Technology selection decisions with multi-year implications (database engine, message queue, auth provider)
- Service boundary decisions (where one service ends and another begins)
- Trade-off analysis where the rejected alternatives need to be on record
- API design decisions that will be consumed by other teams
- Any conversation whose answer will be "why did we build it this way?" from the next engineer
Claude.ai calls the same Claude models available through Zed's AI Panel — the deliberation quality is identical. The difference is that Claude.ai stores the conversation server-side and exports it via a structured JSON format that the WhyChose extractor can process quarterly, surfacing the decision as a structured ADR record you can commit to your /docs/decisions/ directory.
The workflow: deliberate in Claude.ai or ChatGPT → open Zed to implement → export Claude/ChatGPT conversations quarterly → run WhyChose extractor → commit extracted ADR records. The decisions are captured without interrupting the Zed-based implementation workflow.
For decisions already made in Zed's AI Panel
If you've made a significant architecture decision in a Zed AI Panel session that is now closed, reconstruction from the resulting code changes is the only recovery path:
- Read the diff produced by the AI-assisted session. The specific libraries, patterns, and data structures introduced imply the alternatives that were considered and rejected.
- Check git commit messages. When using Zed's AI Panel with edit predictions, the engineer typically writes the commit message — which often summarizes the approach.
git log --oneline -20on the affected files surfaces these. - Reconstruct from the code structure. The presence of specific patterns (event sourcing, CQRS, circuit breakers) implies the absence of alternatives. Write the ADR's Alternatives Considered section from what is not in the codebase, explaining why available patterns were not used.
Related questions
Can you export Zed AI Panel conversation history?
No — Zed has no built-in export for AI Panel conversation history. There is no export button, no data download page in Zed settings, and no GDPR request that returns conversation transcripts. Zed's AI Panel routes requests directly from the Zed client to model provider APIs (Anthropic, OpenAI, Google) without passing through a Zed Industries server — which means Zed Industries has no server-side conversation archive to export. AI Panel conversation state is held in memory for the duration of the Zed session and discarded when Zed is closed. There is no local file equivalent to Cursor's state.vscdb SQLite file; Zed's storage model does not write conversation turns to disk.
Does Zed store AI conversation history server-side?
No. Zed's AI Panel routes requests directly from the Zed client to the configured model provider API endpoint. Anthropic's Claude API, OpenAI's Chat Completions API, or Google's Gemini API receive the requests — not Zed Industries' servers. Zed Industries stores account data (authentication, subscription, billing) and Zeta completion telemetry on zed.dev, but not AI Panel conversation content. This makes Zed architecturally the most direct-routing of the major AI IDEs: Cursor routes through Anysphere's servers as an API intermediary, Windsurf routes through Codeium's model infrastructure, but Zed bypasses any Zed Industries intermediary for AI Panel conversations entirely.
What does a Zed GDPR data request return?
A GDPR data access request to Zed Industries returns account metadata: email address, GitHub OAuth identity, subscription plan, billing history. If Zeta completion telemetry was enabled during the account lifetime, aggregate completion statistics (accepted/rejected counts, anonymized code snippets) may be included. The response does not contain AI Panel conversation transcripts or edit prediction histories — because Zed Industries does not store that content. The account-metadata-only outcome is the same category as GDPR responses from Cursor and GitHub Copilot Chat, but for a different structural reason: Cursor has Anysphere request logs (but doesn't surface them as transcripts), Zed has no such logs because the AI Panel traffic doesn't pass through Zed's infrastructure.
How is Zed different from Cursor and Windsurf for AI export purposes?
All three have no conversation export, but their architectures differ. Cursor routes AI requests through Anysphere's servers as an API intermediary — Anysphere is in the request path, creating server-side request logs (not surfaced in GDPR responses). Windsurf routes through Codeium's model infrastructure and stores partial server-side session metadata for the Cascade experience — more server-side state than Cursor, still no user-accessible conversation archive. Zed routes AI Panel requests directly from the Zed client to model provider APIs with no Zed Industries server in the path — the most pass-through architecture of the three, with zero server-side conversation state at Zed Industries. In practice, all three produce identical outcomes for engineers: zero conversation export, GDPR account metadata only, the same redirect strategy (use Claude.ai or ChatGPT for architecture deliberation instead).
Further reading
- Cursor AI chat export — what's stored, what's lost, and how to capture decisions — the most popular AI IDE in the no-export cluster. Cursor routes through Anysphere's servers as an API intermediary (different from Zed's direct-client routing) and stores some conversation state in a local state.vscdb SQLite file — an unsupported path that Zed doesn't have an equivalent to. The Cursor page covers the local SQLite forensics, the GDPR story, Business/Enterprise plan distinctions (which also don't add conversation export), and the redirect strategy. Both Zed and Cursor are covered in the six-platform AI IDE comparison table on the Cursor page.
- Windsurf AI chat export — what Codeium stores, what's lost, and how to capture decisions — the third major AI IDE in the no-export cluster. Windsurf has the most server-side session metadata of the three (Codeium stores session continuity data for the Cascade experience) — contrasting with Zed's zero server-side conversation state. The AI IDE comparison table on the Windsurf page includes Zed. The practical export outcome is the same: no conversation transcript export for any of them.
- GitHub Copilot Chat export — why there isn't one, and where your history actually lives — the VS Code extension-based AI IDE reference. GitHub Copilot Chat stores conversation state locally only (not transmitted to GitHub's servers even for Enterprise) — different from Zed's in-memory-only model (Zed has no local file) and from Cursor's local SQLite file. The most private of the three and the least recoverable.
- How to export your Claude conversations — the recommended destination for architecture deliberation that would otherwise happen in Zed's AI Panel. Claude.ai uses the same Claude models available through Zed's AI Panel provider configuration. Redirecting deliberation to Claude.ai gives you the same model, permanently stored and exportable via Settings → Account → Export Data → conversations.json.
- How to export your ChatGPT history (2026 guide) — the OpenAI-side equivalent. ChatGPT uses GPT-4o, available as a Zed AI Panel provider. Settings → Data Controls → Export Data produces a conversations.json file compatible with the WhyChose extractor. Redirecting deliberation to ChatGPT preserves the reasoning without changing the model.
- Can you export Claude API conversations? No — and here's why — the architectural explanation for why Zed's AI Panel has the same export gap as all tools that call Claude via the Anthropic Messages API: the API is stateless. Each call includes the full messages array; the server returns a response; nothing is persisted. Zed calling Claude through the API has the same fundamental limitation as any other API client — which is why the redirect to Claude.ai (which is stateful) is the correct solution.
- 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 what makes the redirect strategy concrete: deliberate in Claude.ai or ChatGPT, export quarterly, run the extractor to harvest decision records, commit them to your ADR directory. Zed AI Panel decisions made before you adopted the redirect discipline are not recoverable by the extractor — there is no Zed export format to process.