How do I run a safe Factory AI disk cleanup on a Mac without nuking droid sessions?

A du -sh ~/.factory ~/Library/Caches/factory ~/Library/Application\ Support/Factory on a Mac that has been running the droid CLI daily for a couple of months almost always crosses 6 GB, and 12 to 18 GB is not unusual. None of that shows up in macOS Storage as anything other than the gray System Data bar. The pattern is the same one documented at brtkwr.com when one developer freed 200 GB on a full disk: "After the initial Docker/cache cleanup freed 150GB, going back and asking 'what else?' found another 75GB." Factory AI is one of the "what else" rows on a 2026 dev Mac.

Where does Factory AI store its files on a Mac?

Factory AI's droid CLI fans out across three roots on macOS, and you have to know all three to do an honest cleanup.

The first root is ~/.factory/. This is where droid keeps the things it needs to act as your account: auth.json with your API token, config.toml with model and tool preferences, sessions/ with one folder per conversation, and workspaces/ with per-project metadata. The sessions/ and workspaces/ subtrees are the ones that grow.

The second root is ~/Library/Caches/factory/. This is the macOS-conventional cache directory. Droid writes MCP server logs, tool invocation traces, model response caches, and downloaded artefacts here. macOS will not auto-purge this folder, despite living under ~/Library/Caches/, because it is not marked with the cache attributes Time Machine respects.

The third root is ~/Library/Application Support/Factory/. This is where droid stores larger per-workspace artefacts: file snapshots, embedding indexes for retrieval, and any local working copies of files it has read or modified for context. On a monorepo this directory alone can pass 4 GB.

A cleanup that only clears one root reclaims under a gigabyte. The right combination is where the multi-GB wins live.

Why does Factory AI's disk footprint grow so fast?

Three patterns stack, and they look familiar if you have already audited Claude Code or Codex CLI.

First, every droid run writes a full session transcript: prompts, tool calls, tool outputs, reasoning. Tool outputs dominate. A single cat or git diff against a large repo can put 50 to 200 KB into the transcript, and a long agentic loop runs hundreds of tool calls. Sessions of 10 to 40 MB are routine, and Factory AI never deletes them.

Second, MCP server logs accumulate independently. If you have wired droid to a few MCP servers, the per-project directories under ~/Library/Caches/factory/mcp/ collect raw JSON-RPC traffic. This is the same shape that filled 472 GB on a Claude Code user's Mac, documented in the Claude Code 472 GB postmortem. Factory AI's version is smaller per project but identical in mechanic.

Third, the per-workspace snapshot directory under Application Support keeps a copy of every file droid reads above a size threshold, so it can re-show context on a follow-up turn. A busy week with three or four large repos open can put a gigabyte there without you noticing.

How do I audit Factory AI's disk usage honestly?

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

# Top-level: how much disk does Factory AI claim across all three roots?
du -sh ~/.factory \
       ~/Library/Caches/factory \
       ~/Library/Application\ Support/Factory 2>/dev/null

# Per-subfolder: where inside ~/.factory is the weight?
du -sh ~/.factory/* 2>/dev/null | sort -h

# Per-session: which conversations are the heaviest?
du -sh ~/.factory/sessions/* 2>/dev/null | sort -h | tail -20

The first command is the headline. Under 1 GB, close the tab. Past 5 GB, the second and third tell you whether the weight is in sessions, MCP logs, or workspace snapshots, which decides what you delete. macOS du reports on-disk size, which matches what Storage will show after a delete. Factory AI does not use hardlink-deduplicated storage, so du and reality agree.

What is safe to delete in a Factory AI disk cleanup?

The bright-line answer is in the table below. The pattern is the same one CleanMyDev applies across every AI coding tool: identify the path, classify it, and only touch the safe rows on the first pass.

The rule of thumb is that anything under ~/Library/Caches/factory/ is recoverable on the next run, anything under ~/Library/Application Support/Factory/ rebuilds lazily, and anything under ~/.factory/ except auth.json and config.toml is reversible if you keep a seven-day Trash window.

How do I run the Factory AI disk cleanup safely?

The safe playbook is six steps. The first two are read-only. The last four are reversible because they go to Trash, not to rm -rf.

# 1. Audit (read-only)
du -sh ~/.factory ~/Library/Caches/factory ~/Library/Application\ Support/Factory 2>/dev/null

# 2. Find anything modified in the last 24 hours so you do not touch it
find ~/.factory/sessions ~/Library/Caches/factory \
  -type d -mtime -1 2>/dev/null

# 3. Move the MCP log directory to Trash (lossless)
mv ~/Library/Caches/factory/mcp ~/.Trash/factory-mcp-$(date +%Y%m%d) 2>/dev/null

# 4. Move the response and download caches to Trash
mv ~/Library/Caches/factory/responses ~/.Trash/factory-responses-$(date +%Y%m%d) 2>/dev/null
mv ~/Library/Caches/factory/downloads ~/.Trash/factory-downloads-$(date +%Y%m%d) 2>/dev/null

# 5. Move stale sessions older than 30 days to Trash, keep newer ones
find ~/.factory/sessions -mindepth 1 -maxdepth 1 -type d -mtime +30 \
  -exec mv {} ~/.Trash/ \; 2>/dev/null

# 6. Move workspace snapshots to Trash, keep the index for active projects
mv ~/Library/Application\ Support/Factory/snapshots ~/.Trash/factory-snapshots-$(date +%Y%m%d) 2>/dev/null

Empty the Trash a week later, after you have proved nothing broke. That seven-day window is the safety model: it turns "did I just wipe my active workspace" into a Cmd+click in Finder.

How does Factory AI's footprint compare to Claude Code, Cursor, and Codex?

Roughly the same shape, smaller absolute numbers. The Claude Code mechanic in the cleaning Claude Code disk usage writeup names ~/.claude/projects/, ~/.claude/debug/, and ~/Library/Caches/claude-cli-nodejs/--mcp-logs-*/ as the three growth channels. Factory AI's version is ~/.factory/sessions/, ~/Library/Caches/factory/mcp/, and ~/Library/Application Support/Factory/snapshots/. Same categories, different roots.

Codex CLI uses rollout sessions, the same way Factory AI uses session transcripts, and the growth pattern is the same: name the rollout root, sort by mtime, prune anything older than the active window, leave config alone.

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 Claude Code, Codex CLI, and Factory AI all in daily use will carry 30 to 60 GB of agent state before you look at simulators or Docker.

How do I keep Factory AI's disk usage from creeping back?

Two habits cap it.

First, schedule the audit. A monthly launchd job or a cron line that prints the three du -sh numbers into a log is enough. The point is not to delete on a schedule, the point is to see the number before it becomes a problem. Seeing ~/Library/Caches/factory at 9 GB in month three is information; finding it at 47 GB in month nine when your disk is full is a panic.

Second, prune at the session boundary, not at the time boundary. When you finish a long agentic task and the session is well and truly done, move its directory under ~/.factory/sessions/ to Trash directly. Sessions you actually want to revisit are rare, and the ones you keep are clearly the ones you came back to in the first week. Everything else is dead weight that costs gigabytes per month.

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

Closing

Factory AI is not the worst offender on a 2026 dev Mac, but it is the kind of quiet, growing footprint that only shows up after you go looking. A real Factory AI disk cleanup is three audited roots, a Trash-first sweep of the cache and stale sessions, and the habit of checking the number monthly. Do not delete auth.json or config.toml. Everything else is recoverable for the price of bandwidth on the next droid run. 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

• Cleaning Claude Code disk usage on Mac
• Codex CLI rollout sessions cleanup
• Which AI coding tool uses the most disk on a Mac?