You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Test-products retention is unbounded in practice (100 bundles / 3 days, no config knob) — can fill a disk #524
Each test_sim / test_* run stages a full .xctestproducts bundle (a Binaries/ copy of the built test products) under ~/Library/Developer/XcodeBuildMCP/workspaces/<workspace>/test-products/. In one of the repos I work on, each bundle is ~6.6 GB.
pruneManagedTestProductsDirectory only removes bundles that are either:
older than 3 days (TEST_PRODUCTS_MAX_AGE_MS), or
in excess of 100 retained (TEST_PRODUCTS_MAX_COUNT),
and the sweep only runs while the server is active (1h cooldown). At ~6.6 GB/bundle that permits roughly 660 GB before count-based GC ever triggers. In practice, 20 runs over two days silently consumed 66 GB and contributed to filling my disk.
Root cause
These limits are hardcoded in utils/test-products-lifecycle.js:
and the caller in utils/workspace-filesystem-lifecycle.js only ever passes maxAgeMs (the log max-age, also 3 days) — never maxCount. There is no env/config surface to tune count, age, or a total-size cap, unlike XCODEBUILDMCP_DERIVED_DATA_PATH for derived data.
Request
Expose retention controls, e.g.:
XCODEBUILDMCP_TEST_PRODUCTS_MAX_COUNT
XCODEBUILDMCP_TEST_PRODUCTS_MAX_AGE
XCODEBUILDMCP_TEST_PRODUCTS_MAX_TOTAL_BYTES
and/or lower the defaults given bundles are multi-GB (e.g. keep only the newest N per workspace). A total-size budget would be the most robust guard against filling the disk between the age/count thresholds.
I also downgraded from 2.7.0 to 2.6.2 as it was burning my disk space extremely fast. I basically had to clean up multiple times per day. So 2.7.0 is completely unusable for me due to disk cleaning productivity. IMO this isn't just about cleaning more often. Depending on what workflow / task is active one doesn't always need all this data. This also increases SSD aging. Always isolating everything can also cause extra work instead of reusing reusable artifacts. If I want to analyze code coverage or specific logs my agent may need this data, but in most cases this is not needed.
This issue has been inactive for 30 days. It will be closed in 7 days if no further activity occurs. Add a comment to keep it open, or apply the no-stale label.
Activity
KaiOelfke commentedon Sep 5, 2026
I also downgraded from 2.7.0 to 2.6.2 as it was burning my disk space extremely fast. I basically had to clean up multiple times per day. So 2.7.0 is completely unusable for me due to disk cleaning productivity. IMO this isn't just about cleaning more often. Depending on what workflow / task is active one doesn't always need all this data. This also increases SSD aging. Always isolating everything can also cause extra work instead of reusing reusable artifacts. If I want to analyze code coverage or specific logs my agent may need this data, but in most cases this is not needed.
github-actions commentedon Oct 6, 2026
This issue has been inactive for 30 days. It will be closed in 7 days if no further activity occurs. Add a comment to keep it open, or apply the
no-stalelabel.davidpasztor commentedon Oct 6, 2026
Not stale