Bug Description
~/Library/Developer/XcodeBuildMCP/workspaces reached 143 GB on my machine — 285 .xctestproducts bundles across 391 workspace directories, with 141 GB of that under */test-products/. It was the single largest consumer on a ~1 TB disk that had run down to its last 96 GB.
This is adjacent to #524, but I believe it is a distinct root cause, and the retention knobs proposed there would not reclaim any of this space.
A workspace is keyed by its project path, and it is never garbage-collected when that path stops existing. pruneManagedTestProductsDirectory only sweeps while a server is active for that workspace (with a 1 h cooldown). In agent-driven workflows that create and delete a git worktree per task, the worktree path is gone permanently once the task finishes — so no server ever starts for that workspace again, and neither TEST_PRODUCTS_MAX_AGE_MS nor TEST_PRODUCTS_MAX_COUNT is ever evaluated against its bundles. They become effectively immortal.
Evidence that the sweep never runs for these workspaces
| Bundle age |
Bundles |
Size |
> 3 days (TEST_PRODUCTS_MAX_AGE_MS) |
256 |
126.4 GB |
| > 7 days |
252 |
124.4 GB |
| > 14 days |
242 |
119.4 GB |
| > 30 days |
5 |
2.4 GB |
256 bundles are past the 3-day max age and still on disk. Had the age-based sweep run for those workspaces, all of them would have been removed.
Count-based GC cannot catch this either: the largest number of bundles in any single workspace is 16, far below TEST_PRODUCTS_MAX_COUNT = 100. Every workspace is individually "under limit" while the aggregate sits at 141 GB.
The orphan ratio
A single project accounts for 223 of the 391 workspace directories. That project currently has 17 git worktrees. The remaining ~206 workspaces are keyed to worktree paths deleted weeks ago that will never be built again.
Because each workspace is separately under both thresholds, total consumption is unbounded in the number of project paths ever built, rather than in builds per path. Heavy agent/worktree use makes that number grow monotonically and silently — this accumulated over roughly three months without ever surfacing anywhere a user would normally look, since ~/Library is hidden in Finder and macOS Storage settings folds it into an undifferentiated "Developer" bucket.
Steps to Reproduce
- Use an MCP client workflow that creates a fresh git worktree per task (
git worktree add), which is the default for several coding-agent harnesses.
- Have the agent call
build_sim / build_run_sim / test_sim inside that worktree.
- Complete the task and
git worktree remove the worktree.
- Repeat across a few hundred tasks over several months.
du -sh ~/Library/Developer/XcodeBuildMCP/workspaces
A quick way to see the orphaned share on an affected machine:
WS=~/Library/Developer/XcodeBuildMCP/workspaces
# bundles past the 3-day max age that are still present
find "$WS" -mindepth 3 -maxdepth 3 -name '*.xctestproducts' -type d \
! -newermt "$(date -v-3d +%Y-%m-%d)" -print0 | xargs -0 du -sch | tail -1
# most bundles retained in any single workspace (compare against MAX_COUNT = 100)
find "$WS" -mindepth 3 -maxdepth 3 -name '*.xctestproducts' -type d \
| awk -F/ '{print $(NF-2)}' | sort | uniq -c | sort -rn | head -1
Expected Behavior
Test-product bundles belonging to a workspace whose project path no longer exists should be reclaimed. Two options that would each fix this:
- A global sweep at server start that drops workspace directories whose keyed path is missing from disk, independent of whether a server is ever active for that workspace again.
- A total-size budget across all workspaces (e.g.
XCODEBUILDMCP_TEST_PRODUCTS_MAX_TOTAL_BYTES), rather than per-workspace age/count limits that each pass individually while the aggregate grows without bound.
Actual Behavior
Every workspace ever created persists indefinitely along with its bundles. 126 GB across 256 bundles sits well past the 3-day max age, completely untouched, because the only code path that would delete it requires an active server for a directory that no longer exists.
Notes
Debug Output
XcodeBuildMCP Doctor
Server Version: 2.7.0
## Checks
- xcode: ok Xcode 26.6 - Build version 17F113 (/Applications/Xcode.app/Contents/Developer)
- process-tree: ok Running under Xcode: No; 5 process entries
- axe: ok Available: Yes; UI automation: Yes; Video capture: Yes
- xcodemake: ok Enabled: No; Binary: No; Makefile: Not checked
- mise: warning Running under mise: No; Available: No
- debugger-dap: ok Selected backend: lldb-cli; lldb-dap available: Yes
- manifest-tools: ok Total tools: 82; Workflows: 15
- runtime-registration: ok Enabled workflows: debugging, doctor, project-discovery,
session-management, simulator-management, simulator,
ui-automation, utilities, xcode-ide; Registered tools: 58
- xcode-ide-bridge: ok Workflow enabled: Yes; Connected: No; Proxied tools: 0
- sentry: ok Enabled: Yes
Editor/Client
Claude Code (desktop app)
MCP Server Version
2.7.0
LLM
Claude Opus 5
Bug Description
~/Library/Developer/XcodeBuildMCP/workspacesreached 143 GB on my machine — 285.xctestproductsbundles across 391 workspace directories, with 141 GB of that under*/test-products/. It was the single largest consumer on a ~1 TB disk that had run down to its last 96 GB.This is adjacent to #524, but I believe it is a distinct root cause, and the retention knobs proposed there would not reclaim any of this space.
A workspace is keyed by its project path, and it is never garbage-collected when that path stops existing.
pruneManagedTestProductsDirectoryonly sweeps while a server is active for that workspace (with a 1 h cooldown). In agent-driven workflows that create and delete a git worktree per task, the worktree path is gone permanently once the task finishes — so no server ever starts for that workspace again, and neitherTEST_PRODUCTS_MAX_AGE_MSnorTEST_PRODUCTS_MAX_COUNTis ever evaluated against its bundles. They become effectively immortal.Evidence that the sweep never runs for these workspaces
TEST_PRODUCTS_MAX_AGE_MS)256 bundles are past the 3-day max age and still on disk. Had the age-based sweep run for those workspaces, all of them would have been removed.
Count-based GC cannot catch this either: the largest number of bundles in any single workspace is 16, far below
TEST_PRODUCTS_MAX_COUNT = 100. Every workspace is individually "under limit" while the aggregate sits at 141 GB.The orphan ratio
A single project accounts for 223 of the 391 workspace directories. That project currently has 17 git worktrees. The remaining ~206 workspaces are keyed to worktree paths deleted weeks ago that will never be built again.
Because each workspace is separately under both thresholds, total consumption is unbounded in the number of project paths ever built, rather than in builds per path. Heavy agent/worktree use makes that number grow monotonically and silently — this accumulated over roughly three months without ever surfacing anywhere a user would normally look, since
~/Libraryis hidden in Finder and macOS Storage settings folds it into an undifferentiated "Developer" bucket.Steps to Reproduce
git worktree add), which is the default for several coding-agent harnesses.build_sim/build_run_sim/test_siminside that worktree.git worktree removethe worktree.du -sh ~/Library/Developer/XcodeBuildMCP/workspacesA quick way to see the orphaned share on an affected machine:
Expected Behavior
Test-product bundles belonging to a workspace whose project path no longer exists should be reclaimed. Two options that would each fix this:
XCODEBUILDMCP_TEST_PRODUCTS_MAX_TOTAL_BYTES), rather than per-workspace age/count limits that each pass individually while the aggregate grows without bound.Actual Behavior
Every workspace ever created persists indefinitely along with its bundles. 126 GB across 256 bundles sits well past the 3-day max age, completely untouched, because the only code path that would delete it requires an active server for a directory that no longer exists.
Notes
state/filesystem-lifecycle/last-cleanup, so the lifecycle bookkeeping is already in place — it simply never runs again once a workspace is orphaned.Debug Output
Editor/Client
Claude Code (desktop app)
MCP Server Version
2.7.0
LLM
Claude Opus 5