How do I clean up Windsurf Mac storage without losing my Cascade history?

A du -sh ~/Library/Application\ Support/Windsurf ~/Library/Caches/com.exafunction.windsurf ~/.codeium on a Mac that has been running Windsurf as a daily driver for a couple of months almost always crosses 5 GB, and 10 to 15 GB is routine on monorepo work. None of that surfaces in macOS Storage as anything other than the gray System Data bar. The pattern shows up by name in the brtkwr.com 200 GB cleanup writeup, where one bucket of the audit was "Old editor configs (Cursor, Windsurf, Code-Insiders), 5 GB" and the author's takeaway was blunt: "When you stop using an editor, uninstall it properly or manually delete its Application Support directory." Windsurf storage accumulates, it does not announce itself, and nothing else on the system will reclaim it for you.

Where does Windsurf store its files on a Mac?

Windsurf is Codeium's AI-native IDE, built as a fork of Visual Studio Code, which means it inherits the Electron and Chromium cache layout plus Codeium's own state. A real Windsurf Mac storage audit has to walk three roots, not one.

The first root is ~/Library/Application Support/Windsurf/. This is where the editor keeps everything stateful that survives a quit: per-workspace state under User/workspaceStorage/<hash>/, settings under User/globalStorage/, extension installs under extensions/, file history under User/History/, and the Chromium-side caches under Cache/, Code Cache/, GPUCache/, and logs/. The bulk of the weight lives here.

The second root is ~/Library/Caches/com.exafunction.windsurf/. macOS routes app-marked transient caches here. Windsurf uses it for downloaded artefacts and a few language-server tools. It is smaller than Application Support but still gets to a few hundred megabytes on a busy install.

The third root is ~/.codeium/. This is the Codeium account and Cascade memory store, shared across every Codeium product. It holds your auth token, the rolling project memory Cascade uses across sessions, and a local database of code context. Deleting this folder signs you out and erases Cascade memory, which is why a real cleanup audits it but does not delete from it.

Why does Windsurf disk space grow so fast?

Four growth channels stack, three of them inherited straight from the VS Code lineage.

First is User/workspaceStorage/. Every workspace you open gets a directory keyed by an opaque hash with a state.vscdb SQLite file inside. Open a workspace once, never again, and the folder stays forever. This is the same mechanic the Cursor .pack files writeup names as the path you have to map back to a project before deleting.

Second is Code Cache/ and GPUCache/. Chromium caches V8 bytecode, fonts, and GPU resources for the Electron shell. These two folders alone can pass a gigabyte on a long-running install, and neither holds anything you cannot rebuild on relaunch.

Third is CachedExtensions/ and CachedExtensionVSIXs/. Every extension you install or update writes a copy of the .vsix plus its compiled assets here. The set never shrinks automatically, even after you uninstall an extension from the UI.

Fourth is logs/ and ~/.codeium/database/. Windsurf rotates the visible log files, but the rotated archives stick around indefinitely. The Codeium database side you leave alone, the rotated log archives are pure overhead.

The pattern is the same one the AI coding tools disk footprint 2026 explainer names across the category: transcripts, traces, packfiles, checkpoints, embeddings. Windsurf hits four of the five.

How do I audit Windsurf Mac storage honestly?

Three commands give you the truth. Run them in a normal Terminal, no sudo.

# Top-level: how much disk does Windsurf claim across all three roots?
du -sh "$HOME/Library/Application Support/Windsurf" \
       "$HOME/Library/Caches/com.exafunction.windsurf" \
       "$HOME/.codeium" 2>/dev/null

# Per-subfolder: where inside Application Support is the weight?
du -sh "$HOME/Library/Application Support/Windsurf/"* 2>/dev/null | sort -h

# Per-workspace: which projects carry the biggest workspaceStorage rows?
du -sh "$HOME/Library/Application Support/Windsurf/User/workspaceStorage/"* \
  2>/dev/null | sort -h | tail -20

The first command is the headline. Under 2 GB, close the tab. Past 5 GB, the second tells you whether the weight is in workspaceStorage, the Chromium caches, or the extension folders. The third names the heaviest workspace hashes, which you can map back to projects by inspecting state.vscdb with sqlite3. Windsurf does not use hardlink storage, so du and reality agree.

What is safe to delete in a Windsurf cleanup?

The bright-line answer is in the table below. The same shape applies to every VS Code fork: identify the path, classify it, and only touch the safe rows on the first pass.

Anything under Cache, Code Cache, GPUCache, CachedExtensions, CachedExtensionVSIXs, and logs is throwaway. workspaceStorage is safe per stale entry, not in bulk. User/globalStorage/ and ~/.codeium/ are off-limits.

How do I run the Windsurf cleanup safely?

The safe playbook is seven steps. The first two are read-only. The rest are reversible because they go to Trash, not to rm -rf. Quit Windsurf before step 3 so nothing holds an open file handle.

# 1. Audit (read-only)
du -sh "$HOME/Library/Application Support/Windsurf" \
       "$HOME/Library/Caches/com.exafunction.windsurf" \
       "$HOME/.codeium" 2>/dev/null

# 2. Find anything modified in the last 24 hours so you do not touch active state
find "$HOME/Library/Application Support/Windsurf/User/workspaceStorage" \
  -mindepth 1 -maxdepth 1 -type d -mtime -1 2>/dev/null

# 3. Move the Chromium caches to Trash (lossless)
STAMP=$(date +%Y%m%d)
mv "$HOME/Library/Application Support/Windsurf/Cache" \
   "$HOME/.Trash/windsurf-cache-$STAMP" 2>/dev/null
mv "$HOME/Library/Application Support/Windsurf/Code Cache" \
   "$HOME/.Trash/windsurf-codecache-$STAMP" 2>/dev/null
mv "$HOME/Library/Application Support/Windsurf/GPUCache" \
   "$HOME/.Trash/windsurf-gpucache-$STAMP" 2>/dev/null

# 4. Move the extension caches to Trash (recoverable on next launch)
mv "$HOME/Library/Application Support/Windsurf/CachedExtensions" \
   "$HOME/.Trash/windsurf-cachedext-$STAMP" 2>/dev/null
mv "$HOME/Library/Application Support/Windsurf/CachedExtensionVSIXs" \
   "$HOME/.Trash/windsurf-vsix-$STAMP" 2>/dev/null

# 5. Move rotated log archives to Trash, keep the current logs folder writable
mv "$HOME/Library/Application Support/Windsurf/logs" \
   "$HOME/.Trash/windsurf-logs-$STAMP" 2>/dev/null

# 6. Move workspaceStorage entries older than 60 days to Trash
find "$HOME/Library/Application Support/Windsurf/User/workspaceStorage" \
  -mindepth 1 -maxdepth 1 -type d -mtime +60 \
  -exec mv {} "$HOME/.Trash/" \; 2>/dev/null

# 7. Move the macOS-side cache to Trash
mv "$HOME/Library/Caches/com.exafunction.windsurf" \
   "$HOME/.Trash/windsurf-syscache-$STAMP" 2>/dev/null

Relaunch Windsurf. Open the workspaces you use, log into Codeium if it asks (it usually does not, since ~/.codeium/ was untouched), and confirm Cascade still remembers your project context. Empty the Trash a week later. That seven-day window turns "did I just wipe an active workspace" into a Cmd+click in Finder.

How does Windsurf disk space compare to Cursor, Claude Code, and Codex?

Roughly the same shape on the VS Code-fork side, smaller numbers than Claude Code, larger than a pure CLI like Codex. The Cursor cleanup playbook in the Cursor .pack files writeup names workspaceStorage and Git pack files as the two channels, and Windsurf inherits the first one straight from the same VS Code base. Claude Code's growth is documented in the cleaning Claude Code disk usage guide.

The cross-tool view, with rough month-three footprints on a daily-driver Mac, looks like this.

If you have more than one of these installed, the which AI coding tool uses the most disk breakdown is the right starting point. A Mac with Cursor, Windsurf, and Claude Code all in daily use will easily carry 25 to 50 GB of editor and agent state before you look at simulators or Docker.

How do I keep Windsurf storage from creeping back?

Two habits cap it.

First, schedule the audit, not the deletion. A monthly launchd job that logs the three du -sh numbers is enough. The point is to see the number before it becomes a problem. Seeing the Application Support root at 8 GB in month three is information, finding it at 38 GB in month nine on a full disk is a panic.

Second, prune workspaceStorage at the project boundary. When you close a project you genuinely will not reopen, move its workspaceStorage/<hash>/ folder to Trash the same day. The workspaces you care about are the ones you came back to in the first week.

If you want the same audit across Windsurf, Cursor, Claude Code, Codex, Cline, and Codeium in one read-only pass, that is the job CleanMyDev was built for. Full per-tool footprint on the pricing page at $9.99 lifetime, no subscription, no telemetry, no sudo, no scareware.

Closing

Windsurf is not the worst offender on a 2026 dev Mac, but it carries the quiet VS Code-fork tax: a workspaceStorage that never shrinks, Chromium caches that never rotate, and extension folders that survive every uninstall. A real Windsurf Mac storage cleanup is three audited roots, a Trash-first sweep of the cache directories and stale workspaces, and the habit of checking the number monthly. Leave ~/.codeium/ and User/globalStorage/ alone. Everything else is recoverable for the price of a slightly slower relaunch. If you want the audit and Move-to-Trash safety floor in one app, CleanMyDev is $9.99 lifetime on the pricing page.

Related reading

• Cursor .pack files eating disk space on Mac
• Which AI coding tool uses the most disk on a Mac?
• Gemini CLI Mac disk usage cleanup