Claude Mac app cache location, and moving it elsewhere

A startup disk fills up, a storage scanner points at a folder inside Library, and the name on it belongs to a chat app that was never supposed to be large. The next question is whether that folder can be pointed somewhere else. The short answer is that the desktop app is a Chromium browser in a wrapper, so the folder follows browser rules rather than Mac app rules, and the options for relocating it come from that fact rather than from any setting inside the app.

Three folders, and only one of them is the cache

The data is split across three places in the user Library, and confusing them leads to deleting the wrong one.

The first is ~/Library/Application Support/Claude. This is the profile. Open it and the contents look like a browser profile because that is what it is: Cache, Code Cache, GPUCache, IndexedDB, Local Storage, Cookies, Local State, Preferences. The Model Context Protocol documentation names the same folder when it tells people where to put a config file:

The file is located at: macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Source: modelcontextprotocol.io

The second is ~/Library/Caches/com.anthropic.claudefordesktop. That is the macOS cache directory keyed by bundle identifier, and it is the one macOS itself considers disposable.

The third is ~/Library/Logs/Claude. The same documentation names this one as the place where connector logs are written. It is text, it is small, and it is not the reason a disk is full.

The folder that grows is the profile, not the folder named Caches. Inside the profile, Cache and Code Cache hold the downloaded web assets and the compiled JavaScript, and both are rebuilt on demand. Anything else in that folder is state: the session that keeps an account signed in, the local settings, the connector configuration.

Why the cache and the profile ended up in different places

This split is not a decision made by the app. It is Chromium behaviour, and it is documented.

Chromium keeps a user data directory that holds "profile data such as history, bookmarks, and cookies, as well as other per-installation local state". On macOS it then derives a second location for the throwaway part:

On Mac OS X and iOS, the user cache dir is derived from the profile dir as follows: If Library/Application Support is an ancestor of the profile dir, the user cache dir is Library/Caches plus the relative path from Application Support to the profile dir. Source: chromium.googlesource.com

That rule explains a detail people find odd. A desktop app built on Electron sets its own product directory name, and the framework default is documented as the app data directory "appended with your app's name", which on macOS puts it under ~/Library/Application Support. Whether the disk cache follows the Chromium derivation into ~/Library/Caches or stays inside the profile depends on how the wrapper was configured.

The practical consequence: checking only ~/Library/Caches and concluding the app is small is a mistake. The bulk usually sits beside the session data, one folder over.

Measuring it before deciding anything

Storage tools in System Settings group things by category, and a wrapped web app lands under Applications or Other depending on the tool. That grouping hides the shape of the problem, because it reports one number for a folder whose parts behave very differently.

A per subfolder measurement takes one command in Terminal and answers the question the storage panel does not:

du -sh ~/Library/Application\ Support/Claude/*

Sorting that output makes the decision obvious. If Cache and Code Cache dominate, the fix is deletion and the folder will refill at a predictable rate, which is a maintenance schedule rather than a relocation project. If the large items are named after features rather than caches, deletion buys very little, because those are the parts the app will download again immediately or cannot regenerate at all.

Two more numbers matter before touching anything. The first is how much free space the startup disk actually needs, which is more than most people assume once snapshots and swap are counted. The second is how fast the folder grows: measure, use the app for a week, measure again. A folder that returns to its previous size in three days is telling you that relocation is the only durable answer. A folder that takes three months to get back is telling you to do nothing except repeat the deletion occasionally.

Finder can do the same job without Terminal. Open the profile folder, switch to list view, and add the Size column, though Finder calculates folder sizes lazily and can take a while on a directory holding tens of thousands of cache files.

What a custom location can actually mean

Three routes exist. They are not equivalent, and only one of them is available to somebody who did not build the app.

Route	Who can use it	Survives an update	What it moves
A setting inside the app	Nobody. There is no such preference	n/a	n/a
--user-data-dir on launch	Anyone willing to launch from a script	Yes, but only when launched that way	The whole profile
Symlink the folder	Anyone	Usually	The whole profile, or one subfolder

The middle route is worth understanding even if it is not the one to pick. Chromium documents that "on most platforms, the user data directory can be overridden by passing the --user-data-dir command-line flag to the Chrome binary". Wrappers built on the same engine pass that flag internally to their own helper processes, which is why the switch turns up in the process list of a running Electron app pointing at the Application Support folder.

The catch is delivery. Double clicking an icon in the Dock launches the binary with no arguments. Getting a flag in front of it means launching from Terminal every time, or wrapping the launch in a script and using that instead of the real icon. At that point the icon in the Dock and the thing that actually runs have diverged, which is its own maintenance problem.

The symlink route, and the two ways it goes wrong

The route most people end up on is moving the folder and leaving a symbolic link behind. Quit the app completely, move ~/Library/Application Support/Claude to the external volume, then create a link at the original path pointing at the new one. The app opens the old path, macOS follows the link, and nothing inside the app knows the difference.

It fails in two specific ways.

The first is the volume not being mounted. If the external disk is asleep, ejected, or simply not attached when the app launches, the app finds a dangling link. Some apps recreate the folder from scratch at that point, which produces a signed out window and a profile that has to be rebuilt. Reattaching the disk afterwards does not merge the two.

The second is a sync folder. Putting a browser profile inside a folder that syncs to a cloud service means a file lock database and a partially written cache being uploaded and downloaded while the app has them open. Chromium storage is not designed for that, and corruption there is not the kind that announces itself.

A safer variant exists: link only Cache and Code Cache, the two subfolders that are rebuildable, and leave the session data on the internal disk. If the link breaks, the app rebuilds the cache and stays signed in.

What is safe to delete, and what signs you out

Deleting is faster than relocating, and for most people it solves the actual problem, which is a full disk rather than a wrong path.

Quit the app first. A running Chromium process has the cache files open and will write them back.

Then, in order of increasing consequence:

• Cache and Code Cache inside the profile. Rebuilt on next launch. The first launch is slower. Nothing else changes.
• GPUCache, DawnGraphiteCache, DawnWebGPUCache. Shader caches. Same story, smaller.
• ~/Library/Caches/com.anthropic.claudefordesktop. The system already treats this as disposable.
• Local Storage, IndexedDB, Cookies. This is the session. Deleting it means signing in again, and any local preference stored by the web layer goes with it.
• The whole Claude folder. Everything above, plus the connector configuration file that took an afternoon to get right. Copy claude_desktop_config.json out before doing this.

Conversation history is not stored in the cache, so clearing the cache does not remove it. What clearing does remove is the shortcut back in: the next launch starts at a sign in screen.

There is a step worth taking before any of this, and it costs nothing. Copy the whole profile folder to another disk first, then delete from the original. If something turns out to have lived in a subfolder nobody expected, the copy makes it a five minute recovery instead of a rebuild. Delete the copy a week later once the app has proved it still works. The same precaution covers the case where an update changes what the app keeps locally, which happens quietly and is never announced in release notes.

Time Machine complicates this slightly. Cache directories are often excluded from backups by design, so restoring a profile from a backup can produce a folder that is missing exactly the parts that made it large. That is usually fine, because those parts rebuild, but it means a backup is not a reliable way to measure what the folder used to contain.

The same problem, once there are several of these

A single wrapped web app is easy to reason about. The interesting case is the fifth one.

Every site that gets its own desktop app also gets its own profile folder under Application Support, its own cache, and its own growth curve. Five of them means five folders to check when a disk fills, five sessions to re sign in after a cleanup, and five places where the same login cookie may or may not exist. This is the part that surprises people who started with one app and kept going.

Two things make the pile manageable. The first is knowing which sites deserve a separate app at all: the ones open all day, signed into a specific account, that need to appear in the app switcher rather than in a tab strip. The Features page sets out what a standalone window gets over a tab, which is the same trade-off in reverse. The second is choosing the underlying engine deliberately. A tool that builds the app on top of a browser already installed, rather than shipping another copy of Chromium, keeps one profile and one update path instead of adding a new pair each time. The Supported services list is a reasonable way to see which sites are commonly given their own window, and the Guide covers where the resulting app stores its data before any of it accumulates.

What to change first

Quit the app, delete Cache and Code Cache inside ~/Library/Application Support/Claude, and measure the folder again. If that recovers enough space, stop there, because a custom location adds a failure mode without removing the growth. If the folder refills within a week and the disk is genuinely too small, symlink only those two subfolders to a volume that is always attached, and leave the session where it is. When the count of these apps starts climbing, decide the storage question once for all of them rather than per app, which is what Kagemusha is built around.