Topic: Windsurf AI chat export

Windsurf AI Chat Export — What Codeium Stores, What's Lost, and How to Capture Decisions

Windsurf, built by Codeium, is one of the fastest-growing AI IDEs among senior engineers who want a more agentic experience than Cursor. Its Cascade agent can plan and execute multi-step tasks across your entire codebase — meaning the architecture reasoning that drives significant code changes often happens inside Windsurf. But like every other AI IDE, Windsurf has no conversation export and no data portability path for Cascade sessions. When you close a Cascade flow that reasoned through a significant architecture call, that reasoning is effectively gone. This page explains why — and what to do before it is.

TL;DR

Windsurf (Codeium) has no export for Cascade conversation history. Codeium stores partial session metadata server-side for infrastructure purposes, but this is not a queryable conversation archive and is not accessible via GDPR request or a user-facing export. Some conversation state is written to VS Code extension storage on your local device (same pattern as Cursor and GitHub Copilot Chat). The practical solution: use Claude.ai or ChatGPT for architecture deliberation — same underlying models, permanent export-backed history — and use Windsurf for implementation tasks where the conversation is disposable.

Windsurf's three AI surfaces — what each one is and what it stores

Windsurf surfaces AI assistance through three distinct interfaces, each with a different purpose and different storage characteristics:

Cascade (Windsurf's AI agent)

The primary Windsurf surface and the one where architecture decisions are most likely to happen. Cascade is a multi-step AI agent: you give it a task ("refactor the authentication layer to use JWTs instead of session cookies"), and Cascade plans the work, identifies which files need to change, makes the changes in sequence, runs terminal commands to verify, and iterates until the task is complete. Each Cascade session is called a "Flow." The planning and reasoning that Cascade produces — including the trade-off analysis and approach selection — appears in the Cascade panel. This is the content most engineers would want to export as a decision record.

Cascade supports two modes. Write mode makes direct file changes: Cascade acts autonomously, proposing and applying diffs across multiple files. Chat mode deliberates without writing code: Cascade reasons through options, asks clarifying questions, and presents a recommendation before you ask it to proceed. Chat mode is the higher-value export target because it contains explicit trade-off reasoning — but neither mode has a conversation export.

AI Terminal

Windsurf's AI-assisted terminal: type a natural-language description of what you want to run and Windsurf generates the shell command, with an explanation. Useful for generating complex one-liners, but the interactions are transient — no history, no export, no decision-bearing content in normal use.

Inline completions

Tab-complete suggestions triggered by the cursor position, similar to GitHub Copilot inline completions. Stateless by design — each completion is an independent model call, there is no "conversation" to export, and the suggestion context is discarded after the insertion. No storage, no recovery path.

Of the three, Cascade is the only surface where engineers have extended deliberations that might contain architecture-quality decision reasoning. The rest of this page focuses on Cascade.

Codeium's data model — what is stored and where

Windsurf's data model differs from Cursor's in one important respect: Codeium has its own server-side AI infrastructure (its own fine-tuned models, its own inference endpoints) rather than being a pure pass-through to OpenAI or Anthropic APIs. This means more session context lives on Codeium's servers than in Cursor's purely API-routed model. But "more metadata stored" does not mean "conversation transcripts are recoverable."

What Codeium stores server-side

What Codeium does NOT store (or does not surface)

The practical consequence: even though Codeium stores more than Cursor, the user-accessible portion of that data is the same as Cursor's — account metadata — and the decision reasoning you see in the Cascade panel is not recoverable after the session ends or the workspace is cleared.

What is stored locally

Like Cursor and GitHub Copilot Chat, Windsurf stores conversation state in VS Code's workspace storage on your local device. Windsurf Editor is a VS Code fork; its extension state lives in similar paths:

OS Path
Linux ~/.config/Windsurf/User/workspaceStorage/{workspace-hash}/
macOS ~/Library/Application Support/Windsurf/User/workspaceStorage/{workspace-hash}/
Windows %APPDATA%\Windsurf\User\workspaceStorage\{workspace-hash}\

The workspace hash is derived from the workspace folder path. Some Cascade session state may be present in SQLite extension storage files inside these directories, but the schema is an internal implementation detail of the Windsurf extension and is not a stable, documented format. VS Code Settings Sync does not include workspace storage, so Cascade history from one machine does not transfer when you set up a new device.

What a GDPR data request returns

Codeium's privacy policy and terms of service describe a data access and deletion mechanism for users in GDPR jurisdictions. Submitting a data access request to Codeium returns:

It does not return:

This outcome is structurally similar to GDPR requests for Cursor and GitHub Copilot Chat. The conversation content that would make a GDPR response valuable for decision recovery is not stored in a user-attributable, queryable conversation archive on Codeium's servers — or if it is, it is not surfaced in the GDPR response.

Cascade vs Cursor Composer — same export gap, different architecture

Cascade and Cursor Composer address the same engineering need: multi-file, multi-step AI-assisted code changes driven by a high-level goal. Both have no conversation export. But they approach the problem with different architectures:

Dimension Windsurf Cascade Cursor Composer
AI model source Codeium's own models + optional frontier models (Claude, GPT-4o) Claude (Anthropic API) or GPT-4o (OpenAI API) — Cursor routes to third-party APIs
Planning output Explicit step-by-step plan shown before execution; can be revised before running Proposes diff immediately; less explicit upfront plan display
Server-side session storage Partial — Codeium session metadata None — purely API-routed, no Anysphere server-side session store
Conversation export No No
Local storage VS Code workspaceStorage (Windsurf fork paths) VS Code workspaceStorage (Cursor fork paths, state.vscdb)
GDPR transcripts No — account metadata only No — account metadata only

The architecture difference (Codeium's own model infrastructure vs Cursor's pure API routing) explains why Codeium stores more metadata, but the user-facing export story is the same: no conversation transcript export exists for either tool. Engineers who use Cascade for the planning phase of significant architectural changes and close the session lose the reasoning behind the approach chosen — the alternatives Cascade evaluated, the constraints that shaped the plan, the specific trade-offs accepted.

Windsurf Editor vs VS Code extension

Windsurf comes in two distribution modes:

Both modes expose Cascade. The conversation export story is identical in both — there is no export in either the standalone editor or the VS Code extension.

If you use the VS Code extension mode, the local storage path for conversation state is inside your existing VS Code application data directory rather than a Windsurf-specific path. The workspaceStorage subdirectory structure is the same as described above; only the parent application data folder differs (~/.config/Code/ on Linux vs ~/.config/Windsurf/).

AI IDE chat export comparison

The export gap is consistent across all AI IDE tools — Windsurf, Cursor, GitHub Copilot Chat, and Zed AI all have the same fundamental architecture (VS Code fork or extension, API-routed or model-API-integrated, no server-side conversation archive designed for user export). The contrast with ChatGPT and Claude.ai is stark:

Platform Server-side storage Native export GDPR returns transcripts? Local storage Decision-capture path
Windsurf (Cascade) Partial — Codeium session metadata, not full transcripts No No — account metadata only VS Code extension state (workspaceStorage) Redirect deliberation to Claude.ai or ChatGPT
Cursor Chat No — pure API routing, stateless No No — account metadata only Partial — state.vscdb SQLite, unstable schema Redirect deliberation to Claude.ai or ChatGPT; see Cursor AI chat export
GitHub Copilot Chat Local only — not transmitted to GitHub No No — aggregate telemetry only, not conversation content VS Code workspace storage (local device only) Manual copy-paste at session time; see GitHub Copilot Chat export
Zed AI No — API-routed, stateless No No Partial — local panel state Redirect deliberation to Claude.ai or ChatGPT
Claude.ai (web) Yes — full conversation store on Anthropic's servers Yes — Settings → Account → Export Data → conversations.json Yes — transcripts included n/a 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 n/a Run WhyChose extractor on conversations.json

The pattern is clear: AI IDEs are code editors first. The conversation is a transient context window for implementation assistance — not a product feature designed to make conversation history persistent and portable. ChatGPT and Claude.ai are conversation-storage products first; the AI is what they sell, and the history is what creates the retention loop. The same underlying models (Claude 3.x, GPT-4o) produce completely different portability profiles depending on which product surface you use them through.

The decision-capture strategy for Windsurf users

The practical strategy is to split AI interactions by durability requirement rather than by which tool is more convenient at the moment.

Use Windsurf Cascade for: implementation-mode tasks

Cascade's codebase-aware context makes it excellent for tasks where the conversation is disposable — where the outcome is a code change and the reasoning behind the specific implementation choices doesn't need to outlive the session:

In these cases, the decision (what to implement) was made elsewhere and is visible in the code. The Cascade conversation that produced the diff is not the important artifact — the code change is. You don't need to recover the reasoning for these tasks.

Use Claude.ai or ChatGPT for: architecture deliberation

Redirect conversations to a platform with durable exports when the reasoning itself is the artifact — when a future engineer will need to understand not just what was done but why this approach was chosen over the alternatives:

Claude.ai and ChatGPT can call the same Claude 3.x and GPT-4o models that Windsurf Cascade uses. 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 Windsurf to implement → export Claude/ChatGPT conversations quarterly → run WhyChose extractor → route extracted records to your ADR directory. The decisions are captured without any interruption to your Windsurf-based implementation workflow.

For decisions already made in Windsurf Cascade

If you've made a significant architectural decision in a Cascade session that is now closed, the practical recovery path is to reconstruct the reasoning from the code changes that resulted:

  1. Read the Cascade-generated diff. The specific approach Cascade chose — the libraries, patterns, and data structures it introduced — implies the alternatives that were considered. A diff that adds a circuit breaker library implies that timeout-based resilience and retry-only approaches were implicitly rejected.
  2. Search git log context. Cascade often writes commit messages that summarize the reasoning. git log --oneline -20 on the affected files surfaces any planning summaries Cascade or the engineer committed alongside the changes.
  3. Reconstruct from code structure. The presence of specific patterns (event sourcing, CQRS, saga orchestration) implies the rejected alternatives. Write the ADR's Alternatives Considered section from what is NOT in the codebase, explaining why the patterns that were available were not used.

Related questions

Can you export Windsurf Cascade conversation history?

No — Windsurf has no built-in export for Cascade conversation history. There is no export button, no data download page in settings, and no GDPR request that returns conversation transcripts. Codeium stores partial session metadata server-side for the Cascade experience, but this is not a user-accessible conversation archive. Some session state is written to VS Code extension storage on your local device, but the schema is an internal implementation detail. There is no stable extraction path for Cascade conversation transcripts.

Does Codeium store Windsurf conversation history server-side?

Codeium stores session metadata server-side — account data, usage telemetry, codebase index metadata for Cascade context, and session continuity data. But this is distinct from storing full conversation transcripts in a user-accessible, exportable archive. The GDPR data access request returns account metadata (name, email, subscription, usage counts) rather than conversation transcripts. Codeium's partial server-side storage model is more extensive than Cursor's (which routes purely through external APIs) but less than ChatGPT's (where the full conversation history is explicitly the product).

Does a GDPR data request to Codeium return Windsurf Cascade transcripts?

No. A GDPR data access request to Codeium returns account metadata (name, email, subscription details, billing history, aggregate usage counts) but not Cascade conversation transcripts or Flow session histories. The response is account-metadata-only — the same outcome as GDPR requests to Anysphere (Cursor) and GitHub (GitHub Copilot). Cascade session content is not stored in a user-attributable conversation archive that GDPR access rights apply to in the form of recoverable transcripts.

What is the best way to capture architecture decisions made in Windsurf?

Use Claude.ai or ChatGPT for architecture deliberation instead of Windsurf Cascade 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: Settings → Account → Export Data; ChatGPT: Settings → Data Controls → Export Data), and are compatible with the WhyChose extractor for structured decision extraction. Claude.ai and ChatGPT run Claude 3.x and GPT-4o — the same underlying models that power Windsurf Cascade. The reasoning quality is identical; the difference is permanent exportable storage. Use Windsurf for implementation tasks where the conversation is disposable. Export Claude/ChatGPT conversations quarterly and run the WhyChose extractor to surface architecture decisions as ADR-compatible records.

Further reading