Skip to content

[Bug]: Orphaned workspaces are never swept — test-products for deleted project paths persist forever (126 GB past max age) #526

Description

@dpearson2699

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

  1. 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.
  2. Have the agent call build_sim / build_run_sim / test_sim inside that worktree.
  3. Complete the task and git worktree remove the worktree.
  4. Repeat across a few hundred tasks over several months.
  5. 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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions