If Cursor is taking up space on your Mac, the app itself is rarely the reason. AI coding tools keep far more than their apps: chat and agent histories, checkpoints of the files they edit, logs, extension copies and staged updates.
Increasingly, they also keep whole extra copies of your projects in Git worktrees. Each tool keeps all of this in its own folders, and most never mention them.
The big items differ by tool. Cursor's chat database can grow to many gigabytes. Claude Code keeps transcripts and, if you connect MCP servers, logs that have reached hundreds of gigabytes in reported cases. Codex and Claude Code create worktrees, each a full checkout with its own dependencies. Claude's desktop app downloads a Linux virtual machine for Cowork.
Most of it can be trimmed safely, but not all of it the same way. Caches, logs and staged updates come back by themselves. Chat histories, transcripts and worktrees can hold work you'd miss, and each tool has its own command, setting or button for them.
The sections below go through each tool, what it keeps, where, and what to do about it.
Why AI coding tools take so much space on a Mac
An editor used to keep a few settings and a cache. An AI coding tool records everything it does so you can review, resume or undo it, and it works on copies of your code so it doesn't collide with you. Both habits cost disk space.
What do AI coding tools keep?
Almost every tool keeps some mix of these:
- Caches: web, code and graphics caches of the app, which it rebuilds by itself.
- Logs: the app's own, and logs of the MCP servers or tools it talks to.
- Conversation history: transcripts or a database of every chat, often with full tool output.
- Checkpoints: copies of files from before the agent edited them, so you can roll back.
- Worktrees: extra working copies of a repository, one per task or session.
- Extensions and versions: the editor extension, sometimes several versions of it, and the tool's own binaries.
- Virtual machines: a sandbox to run tasks in, such as Claude's Cowork.
The first two are safe to clear. The middle three can hold work. The last two depend on whether you still use them.
A worked example from one Mac
On one developer's Mac we checked while writing this, with Claude Code, Codex, VS Code and Cursor installed, the AI tools' own data added up to well over 50 GB. The apps themselves were a small part of it.
| What | Where | Size on that Mac |
|---|---|---|
| Claude Code worktrees, one repository | .claude/worktrees inside the project | 36 GB in 17 worktrees |
| Codex worktrees | ~/.codex/worktrees | 14 GB in 21 worktrees |
| Codex sessions | ~/.codex/sessions | 3.2 GB |
| AI extensions, three versions of each | ~/.vscode/extensions | About 3.3 GB |
| Claude Code transcripts | ~/.claude/projects | 1.7 GB |
| VS Code's downloaded update | ~/Library/Caches/com.microsoft.VSCode.ShipIt | 1.4 GB |
| The Claude app's web caches | ~/Library/Application Support/Claude | About 1.4 GB |
Nothing there was broken. The worktrees were the bulk, and most of their size was each copy's own dependencies and build output, the same weight a project's node_modules folder carries.
How do you find out which tool is using the space?
Most of these folders are hidden or buried in your Library folder, so Finder doesn't show them by default. Check them one at a time:
- In Finder, choose Go › Go to Folder.
- Type a location from the tables in this post, such as
~/or.claude ~/, and press Return.Library/ Application Support/ Cursor - Select a folder inside it and choose File › Get Info, or press Command-I, to see its size.
- Close the window without moving anything until you've read what that folder holds.
Start with worktrees and conversation histories, the two kinds that grow with use, then caches. Folders in your Library folder belong to the tool that made them, so its own settings are usually the better way to shrink them.
Which Storage settings category counts them?
macOS doesn't know these folders. In System Settings › General › Storage, files in your Library folder usually count toward System Data, which Apple describes as files that don't fall into the other categories. Worktrees inside a project folder count wherever that project lives, often Documents.
The path is the same in macOS 27 Golden Gate and macOS 26 Tahoe. Storage settings can't remove any of this for you; that happens in Finder or in the tool itself.
Cursor taking up space on a Mac: where it goes
Cursor is built on VS Code, so it keeps VS Code's kinds of data in its own folders, plus its AI features' history. Most of it is in two places: ~/ and the hidden ~/ folder in your home folder.
Where does Cursor keep its data?
| Location | What it holds | Can you clear it? |
|---|---|---|
~/Library/Application Support/Cursor/Cache, CachedData, Code Cache, GPUCache, logs and similar | Web, code and graphics caches, downloaded extension packages, session logs | Yes, with Cursor quit |
~/Library/Application Support/Cursor/User/globalStorage/state.vscdb | A database with chat and agent history and other state | Only through Cursor |
~/Library/Application Support/Cursor/User/workspaceStorage | One folder of state per project you've opened | Review first |
~/.cursor/extensions | Extensions you installed in Cursor | Uninstall in Cursor |
~/.cursor/projects | Per-project agent data, including transcripts | Review first |
/Applications/Cursor.app | The app, about 1 GB | Only by removing Cursor |
The Cursor caches and logs entry covers the first row. Cursor rebuilds those caches as it runs, so removing them costs a slower first start and the logs of earlier sessions, nothing else.
Why is state.vscdb so large?
It's where Cursor keeps your chat and agent history. On Cursor's forum, a user with a 256 GB MacBook Air found it at about 12.4 GB in June 2026, with a backup copy of almost the same size beside it. Another user in July 2026 reported a single state.vscdb of 188 GB.
A Cursor team member replied in both threads that the growth matches how Cursor currently stores chat and agent history, and that the team is tracking a way to clean it up automatically. Until then, it grows as long as you keep chats.
How do you shrink Cursor's chat database safely?
The steps Cursor's team gave on its forum all happen inside Cursor:
- Open Cursor and press Command-Shift-P to open the Command Palette.
- Run Developer: GC Agent KV Blobs. It clears orphaned chat and agent data and compacts the database without deleting chats. It can take a while and shows its progress. If the command is missing, update Cursor.
- If the file is still large, run Developer: Delete Old Chats… and choose a cutoff, such as 30 days. Older chats are deleted for good, then the database is compacted.
Compacting a database needs free disk space while it works. On a nearly full Mac, free a little room elsewhere first.
What about state.vscdb.backup?
The backup is a fallback copy Cursor reads only if the main file is damaged. Cursor's team said it can be removed with Cursor quit, at the cost of that safety net, and suggested moving it to an external drive if you'd rather keep it.
Don't delete state.vscdb itself. Cursor's team warned that doing so can leave existing chats stuck on "Loading Chat…", and the file holds checkpoints as well as chats.
What was the snapshots bug?
In March 2026, users of Cursor 2.6 reported a helper process writing tens of gigabytes into a snapshots folder of .pack files within minutes of launch. A reply on Cursor's forum said the team knew about the bug, that deleting the folder doesn't help because Cursor recreates the files, and suggested version 2.5 as a workaround.
It's a reminder that a sudden jump is often a bug in one version. If Cursor's folder grows by gigabytes in a day, check Cursor's forum for your version before removing anything.
Does Cursor share extensions with VS Code?
No. Cursor installs extensions into ~/, separate from VS Code's. If you use both editors, the same extension, language server or debugger is stored twice. The catalog's entry for Cursor's extensions treats that folder as Review first: uninstall what you don't use in Cursor's Extensions view, never by deleting the folder.
VS Code, Windsurf and other VS Code-based editors
VS Code, Windsurf, VSCodium and Cursor share most of their code, so they also share their storage habits. Knowing VS Code's helps with all of them. The post on VS Code's caches, extensions and workspaces goes deeper.
Which caches clean themselves up?
VS Code keeps a web cache, compiled code caches, graphics shader caches, downloaded extension packages and session logs in ~/. Its own code trims old code caches, logs and extension downloads over time.
That keeps them from growing without limit, and they're safe to remove with the editor quit. The same holds for Windsurf's and VSCodium's folders, named after each app in Application Support.
What is workspaceStorage, and does it ever shrink?
Every folder you open gets its own subfolder in ~/, named with a long hash. It holds that project's editor state, and extensions keep their per-project data there. GitHub Copilot's chat sessions are one example.
VS Code's cleanup only removes this storage for empty, unused windows. Folders for projects you opened once, moved or deleted stay. Each subfolder has a small file, workspace.json, that names the project it belongs to; select it in Finder and press Space to read it with Quick Look.
A folder whose project no longer exists is a leftover. Removing it, with the editor quit, loses only that project's editor state and any chats stored there. Most are small; check the size with File › Get Info before you bother.
Why are there several versions of the same extension?
When an extension updates, VS Code marks the old version for removal and deletes it during a later cleanup. Until then, both versions take space.
On the Mac we checked, AI extensions made this visible. Three versions of OpenAI's Codex extension took about 850 MB each, and three versions of the Claude Code extension about 230 MB each, because each bundles its own native program.
Those older copies aren't used once an update is done, and VS Code removes them in its own cleanup. Don't delete folders in the extensions folder to hurry it; uninstall extensions you don't use in the Extensions view instead.
What is the ShipIt folder in Caches?
Apps built on Electron, including VS Code and Claude's desktop app, download each update into a folder in ~/ whose name ends in ShipIt, and install it when you quit. A downloaded update is a full copy of the app, so it can take a gigabyte or more.
The catalog's Safe entry for these folders notes that removing one only means the app downloads a waiting update again. Quitting the app normally lets the update install, which is usually the better fix.
GitHub Copilot: in the editor and in Terminal
Copilot lives in two places on a Mac: inside VS Code and other editors as an extension, and as Copilot CLI in Terminal. Each keeps history in its own way.
Where does VS Code keep Copilot chats?
Copilot Chat stores sessions per project, in that project's workspaceStorage folder. A VS Code feature request on GitHub explains the catch: the folder's name comes from the project's location, so moving or renaming a project leaves its old chats in a folder the Chat view no longer finds.
To remove a session in VS Code, right-click it in the sessions list and choose Delete. VS Code's documentation says deleting a session is irreversible, while archiving one doesn't delete it. To keep a conversation first, Chat: Export Chat... in the Command Palette saves it as a JSON file.
Do Copilot sessions make worktrees?
They can. VS Code's documentation says deleting a Copilot session also removes any worktrees created for it, and a worktree shared by several sessions goes when the last of them is deleted or archived.
For worktrees left over from sessions you've stopped using, run Chat: Open Worktree Cleanup from the Command Palette. It lists inactive session worktrees and lets you remove the ones you don't need.
What's in Copilot CLI's folder?
Copilot CLI keeps its settings, session history, logs and customizations in ~/, and GitHub's documentation says its Copilot app keeps sessions there too. That documentation includes a table of what you can safely delete.
Item in ~/.copilot | GitHub's verdict | What deleting it does |
|---|---|---|
logs/ | Yes | Nothing; logs are created again each session |
plugin-data/ | Yes | Plugins create it again as needed |
session-state/ | With caution | Past sessions can't be resumed |
session-store.db | With caution | Cross-session data goes; the file comes back |
config.json | With caution | Resets state, including sign-in |
agents/, skills/, instructions/ | Not recommended | Your own customizations are lost |
GitHub also notes that sessions run locally are synced to your GitHub account by default, so a local session folder isn't always the only copy. Copilot CLI's own session commands delete a session and ask whether to delete the synced copy too. Remove installed plugins with Copilot's uninstall command, so its records stay accurate.
Claude Code: transcripts, checkpoints, logs and worktrees
Claude Code keeps most of its data in the hidden ~/ folder, plus logs in your Caches folder and worktrees inside your projects. It cleans up much of it by itself.
What's in the .claude folder?
| Location | What it holds | Cleaned up by itself? |
|---|---|---|
~/.claude/projects | Session transcripts per project, and Claude's auto memory | Transcripts after 30 days; memory kept |
~/.claude/file-history | Copies of files from before Claude edited them, for rewinding | Yes, with the same retention |
~/.claude/debug | Debug logs, only while debug logging is on | After 30 days |
~/.claude/shell-snapshots, tasks, backups | Working files for sessions | Yes, with the same retention |
~/.claude/settings.json, CLAUDE.md, skills, agents | Your settings and your own customizations | Never; keep them |
~/Library/Caches/claude-cli-nodejs | Logs of traffic with MCP servers | No |
To open the folder in Finder, choose Go › Go to Folder, type ~/ and press Return. Folders whose names start with a period are hidden by default; that's why you don't see it in your home folder.
How long does Claude Code keep transcripts?
The catalog's entry for Claude Code's conversation history explains it: Claude Code saves every session as a full transcript, including tool calls and their results, and deletes transcripts older than its cleanup period, 30 days by default. Auto memory, the notes Claude keeps about each project, stays.
To keep less, lower the cleanupPeriodDays setting in Claude Code's settings file. Claude Code's changelog says the same sweep also covers its tasks, shell snapshots and backups folders. A transcript you remove by hand is a session you can't resume.
Sessions you run from Claude's desktop app are an exception. The changelog notes that transcript cleanup keeps sessions written by the desktop app while they're in the app, with a separate setting to cap that.
Why can MCP logs grow so large?
Claude Code records its traffic with each MCP server you connect in ~/, one folder per project and server. The logs include full tool results, so a server that returns images or large documents makes them grow fast.
One GitHub issue from June 2026 describes 242 GB of these logs, growing about 10 GB a day, from custom MCP servers returning images and embeddings. The reporter notes that cleanupPeriodDays doesn't cover them. That case is extreme, but the folder is worth a look if you use MCP servers heavily.
The Claude Code MCP logs entry rates the folder Safe: Claude Code creates new logs as it runs and doesn't need the old ones. Moving the folder to the Trash in Finder costs only the history you'd use to troubleshoot an old problem.
What about debug logs?
Claude Code writes debug logs to ~/ only while debug logging is on, after the debug command or when it's started with its debug option. Its changelog notes they're no longer written by default. Earlier versions wrote more: a January 2026 GitHub issue reported 472 GB across debug and MCP logs after months of heavy use.
They're safe to remove, and Claude Code deletes those older than its cleanup period by itself.
Where do Claude Code's worktrees go?
When you start Claude Code in a worktree, or run background agents that each get one, it creates them in the project's own .claude/ folder. Each is a full working copy of your repository. Once you install dependencies or build in it, it carries its own node_modules, build output and caches.
That's why worktrees were the largest item on the Mac we checked: 17 of them in one repository took 36 GB. The node_modules guide explains why a single project's dependencies can weigh gigabytes.
Remove worktrees through Claude Code. When you exit a session that started in a worktree, it asks whether to keep or remove it. Its agents view can delete background sessions with their worktrees, and it warns before discarding a worktree with unpushed commits.
Deleting a worktree folder in Finder loses any uncommitted work in it and leaves Git's record of the worktree behind. Commit or push what you want to keep, then remove it in the tool.
Does Claude Code keep old versions?
The native installer keeps the program in ~/. On the Mac we checked, it held three recent versions, about 200 MB each. The Claude Code extension for VS Code is a separate copy in VS Code's extensions folder, with the old-versions habit described above.
Claude's desktop app and Cowork
The Claude app for Mac keeps its data in ~/ and its logs in ~/. Most of it is small, with one large exception.
Caches and logs
Like other Electron apps, Claude keeps web, code and graphics caches next to its settings. The catalog rates them Safe: Claude rebuilds them, and you stay signed in. Its logs, including a log for each MCP server you connect, are safe to remove too, with the app quit.
Why is the Cowork folder so big?
Claude runs Cowork tasks in a small Linux virtual machine stored in ~/. The Claude Cowork VM bundle entry explains that its disk grows as tasks install packages and create files, and space freed inside it isn't returned to your Mac, so it often reaches 10 GB or more.
GitHub issues report bundles of 10 to 25 GB, regrowing within hours after removal for people who use Cowork. The issue tracking it was still open in October 2026.
How do you reset the Cowork virtual machine?
In Claude, choose Help › Troubleshooting › Delete Cowork VM Bundle and Restart. Running Cowork tasks stop, Claude restarts, and the next Cowork task waits while it downloads the bundle again. Anything installed inside the virtual machine is gone.
Your Cowork conversations are stored separately and aren't affected. A GitHub issue places that session state in a folder named local-agent-mode-sessions in the same Claude folder. Don't remove that folder to save space.
OpenAI Codex: sessions, history and worktrees
Codex runs as a command-line tool, an editor extension and in OpenAI's desktop app, and all three keep their state in ~/. OpenAI's documentation calls it CODEX_HOME and lists config, auth, logs, sessions and skills among what it holds.
Sessions and history
Codex saves each thread as a file in ~/, in folders by year, month and day, so you can resume or review it. The catalog's entry for Codex's session history rates it Review first: the files hold the full conversation and tool output, and a removed file is a thread you can't resume.
Its documentation also describes a history file of past sessions, and a setting, history.max_bytes, that caps it: past the cap, Codex drops the oldest entries and keeps the newest. Another setting turns local history off.
How many worktrees does Codex keep?
OpenAI's documentation is candid about the cost: worktrees can take a lot of disk space, because each has its own repository files, dependencies and build caches. Codex creates them in ~/ by default and keeps the 15 most recent ones it manages.
It skips worktrees tied to a pinned chat, a chat still running, or a permanent worktree, so you can have more than 15. Codex deletes a managed worktree when you archive its chat, or when it needs to stay under the limit, and saves a snapshot first so you can restore it from the chat.
To keep fewer, lower the limit in Codex's settings, or archive chats you've finished. To keep them on another disk, open Settings › Worktrees and change Worktree root.
What are the other folders in .codex?
The folder also holds generated images, plugins, caches and SQLite databases of state and logs. On the Mac we checked, none came near the worktrees or sessions. Leave config.toml and auth.json alone: one is your configuration, the other can hold your sign-in.
What's safe to remove, tool by tool
Every tool mixes data that comes back by itself with data that's the only record of your work. This table sorts the main items by what removing them costs.
| Item | Level | What removing it costs | How |
|---|---|---|---|
| Editor caches and logs (Cursor, VS Code, Windsurf) | Safe | A slower first start | Finder, with the app quit |
| Claude app caches and logs | Safe | A slower first start | Finder, with the app quit |
| Claude Code MCP and debug logs | Safe | Old logs for troubleshooting | Finder |
| Staged updates (ShipIt folders) | Safe | The update downloads again | Finder, or quit the app to install |
| Claude Cowork virtual machine | Usually safe | A download, and what was installed in it | Claude's Help menu |
| Chat histories and transcripts | Review first | Sessions you can't resume | Each tool's own delete or retention setting |
| Worktrees | Review first | Uncommitted work in them | Each tool's own removal |
What should you never delete?
Some files in these folders look like clutter and aren't:
- Settings and instructions: VS Code's and Cursor's User/settings.json, Claude Code's settings.json and CLAUDE.md, Codex's config.toml.
- Your own customizations: skills, agents, prompts and hooks you wrote. They exist nowhere else unless you keep them in a repository.
- Sign-in files: Codex's auth.json, Copilot CLI's config.json. Removing them signs you out.
- Cursor's state.vscdb: shrink it with Cursor's commands instead.
- Memory: Claude's auto memory in each project's folder, which Claude Code keeps when it cleans up transcripts.
App preferences and state aren't caches. They're small, and removing them only resets the tool.
Mistakes to avoid
- Deleting a whole tool folder to start over. Removing
~/,.cursor ~/or.claude ~/takes your settings, history and customizations with the caches..codex - Removing worktrees in Finder. Uncommitted work goes with them. Use the tool's own removal.
- Clearing a database while the app runs. Quit the tool first, or it may write the file back, or break.
- Pasting cleanup commands from a forum. Several threads suggest database commands that delete chat history; the in-app commands do the same with less risk.
What if you've stopped using a tool?
Then most of its data has no reason to stay. Remove the app first, the usual way: quit it, including any icon in the menu bar, and drag it from Applications to the Trash. Dragging an app away leaves its folders behind, so its history, caches and extensions stay.
Before you remove those, export anything you want to keep: a conversation you refer to, skills or instructions you wrote, a worktree with work you haven't committed. Then the tool's folders, listed in the tables above, can go to the Trash.
Leave the folders of tools you still use, even rarely, to those tools. Removing a whole folder resets the tool to a first launch.
Keep AI coding tools from filling your Mac again
Most of this growth is predictable, and each tool has a setting or habit that caps it.
Set retention where the tool offers it
- Claude Code: lower cleanupPeriodDays in its settings file to keep transcripts and working files for fewer days.
- Codex: lower the worktree limit in its settings, and set history.max_bytes to cap its history file.
- Cursor: run Developer: Delete Old Chats… every few months.
- Copilot: delete or archive sessions you've finished, and run Chat: Open Worktree Cleanup now and then.
Finish sessions properly
Worktrees are the easiest thing to forget. When a task is merged, archive its chat in Codex, remove its worktree when Claude Code asks on exit, or delete the session in VS Code. Each removes the worktree with it.
Watch the outliers once a month
A tool that suddenly grows by gigabytes a day usually has a bug or a chatty integration: an MCP server returning images, a version with a runaway folder.
Once a month, check the folders from the table at the top of this post with File › Get Info. If one has jumped, look at the tool's issue tracker for your version before deleting anything.
Local models are a separate question
If you pair these tools with local models through Ollama or LM Studio, those models are usually the largest AI data on a Mac, at several gigabytes each. They're covered in how to delete Ollama models.
- Editor caches (VS Code, Cursor)1–20 GB · Safe
- Claude Cowork virtual machine10–21 GB · Usually safe
- Electron update downloads0.2–3 GB · Safe
Typical ranges on Macs that use these tools, from the research behind the app's catalog. Worktrees and chat histories depend on your projects and are left out.
How the app does it
Wombit explains these folders like everything else on the disk. Select one in the map or the list, and you see what it is, how safe it is to remove and what removing it costs, from the catalog's entry. File names and paths never leave your Mac.
Cleanup lists them by level:
- Editor caches and logs for VS Code, Cursor, Windsurf and VSCodium, the Claude app's caches and logs, Claude Code's MCP and debug logs, and Electron apps' staged updates are Safe. They count toward the safe total and start checked. Folders go to the Trash, where you can put them back.
- The Cowork virtual machine is Usually safe, explained with Claude's own Help menu step.
- Claude Code's transcripts, Codex's sessions and your editor extensions are Review first. They're explained, with each tool's own way to remove them, and never start checked.
~/
Library/ Application Support/ Cursor/ {Cache,CachedData,CachedExtensionVSIXs,Code Cache,DawnGraphiteCache,DawnWebGPUCache,GPUCache,logs} Web, code and graphics caches, downloaded extension packages and session logs that Cursor keeps in its data folder.
Safe · Moves it to the Trash
~/
Library/ Application Support/ Code/ {Cache,CachedData,CachedExtensionVSIXs,Code Cache,DawnGraphiteCache,DawnWebGPUCache,GPUCache,logs} Web, code and graphics caches, downloaded extension packages and session logs that Visual Studio Code keeps in its data folder.
Safe · Moves it to the Trash
~/
Library/ Caches/ claude-cli-nodejs Logs of the messages Claude Code exchanges with MCP servers, kept in a folder for each project and server.
Safe · Moves it to the Trash
~/
Library/ Application Support/ Claude/ vm_bundles The Linux virtual machine that the Claude desktop app downloads to run Cowork tasks in a sandbox.
Usually safe · Explained only: the app shows you how
~/
.claude/ projects Claude Code conversation history
Transcripts of your Claude Code sessions, in a folder for each project, along with Claude's auto memory notes.
Review first · Explained only: never removed
~/
.codex/ sessions Saved Codex threads, one file per session in folders by date, used to resume past work.
Review first · Explained only: never removed
Seeing all of this is free. Cleanup is PRO, one payment of $4.99 with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.
Frequently asked questions
Why is Cursor using so much storage on my Mac?
Usually because of its chat and agent history, kept in a database called state.vscdb in Cursor's globalStorage folder, which grows as long as you keep chats. Cursor's team suggests running Developer: GC Agent KV Blobs from the Command Palette to compact it, and Developer: Delete Old Chats… to remove older chats.
Is it safe to delete Cursor's cache folder?
Yes. Cursor's Cache, CachedData, Code Cache, GPUCache and logs folders in its Application Support folder are rebuilt as it runs. Quit Cursor first. Your settings, extensions and chat history are kept elsewhere and aren't affected.
How do I delete Claude Code's conversation history?
Claude Code removes transcripts older than its cleanup period, 30 days by default, by itself. To keep them for less time, lower cleanupPeriodDays in its settings file. A transcript you remove is a session you can no longer resume, and Claude's auto memory for each project is kept.
Can I delete the Claude vm_bundles folder?
It holds the Linux virtual machine Claude's desktop app uses for Cowork, and it often reaches 10 GB or more. Reset it with Help › Troubleshooting › Delete Cowork VM Bundle and Restart in Claude. Claude downloads it again the next time you use Cowork, and your Cowork conversations are kept.
Where does Codex store its data on a Mac?
In the .codex folder in your home folder, which OpenAI calls CODEX_HOME. It holds your configuration, sign-in, sessions, logs and, for the desktop app, worktrees. Codex keeps its 15 most recent managed worktrees by default, and you can lower that in its settings.
Where are GitHub Copilot chats stored in VS Code?
Copilot Chat keeps sessions per project in VS Code's workspaceStorage folder, inside its Application Support folder. Delete a session by right-clicking it in the sessions list and choosing Delete; VS Code says that can't be undone. Copilot CLI keeps its sessions separately, in the .copilot folder in your home folder.
Why are there old versions of extensions in my VS Code extensions folder?
When an extension updates, VS Code marks the old version for removal and deletes it in a later cleanup, so both can sit there for a while. AI extensions that bundle their own programs make this noticeable, at hundreds of megabytes per version. Uninstall extensions you don't use in the Extensions view rather than deleting folders.
Do AI coding tools make my Mac slower?
Their stored data doesn't slow a Mac by being there; clearing caches frees space, not speed. A nearly full disk can get in the way of updates and large builds, though, so trimming logs, old worktrees and chat histories helps when space runs short.
Sources
- Change Storage settings on Mac · Apple
- macOS state.vscdb grew to 12.4 GB on a 256 GB MacBook Air · Cursor Community Forum
- Chat sessions · Visual Studio Code
- GitHub Copilot CLI configuration directory · GitHub
- Worktrees · OpenAI
- Claude Code changelog · Anthropic