Describe the bug
When Copilot CLI builds or tests Xcode projects, it writes Xcode derived data inside its own session-state directory rather than the standard Xcode location. I've found it in two layouts:
- ~/.copilot/session-state//files/apptests-deriveddata/
- ~/.copilot/session-state//files/diagnostics/DerivedData/
These contain the usual derived data content (Build/, CompilationCache.noindex/, SourcePackages/, ModuleCache.noindex/, Info.plist, etc.). On my machine a single session's DerivedData folder had grown to over 20 GB. And I had instances of both paths listed above, so 40GB+ used by stale Copilot sessions.
Why this is a problem
- Silent, unbounded disk growth. Derived data is large and regenerable, but it's stored per-session with no apparent retention policy, so it accumulates until the user manually prunes sessions.
- Hidden from every existing cleanup path. Because it lives in a hidden dot-folder rather than ~/Library/Developer/Xcode/DerivedData, it's invisible to Xcode's own cache management, to disk-space tools, and to Xcode cleanup utilities (e.g. DevCleaner). Users have no reason to suspect their vanishing disk space is under ~/.copilot.
- Not documented. The session-state docs describe events.jsonl / workspace.yaml, but I couldn't find any mention that multi-gigabyte build artefacts are also stored there, and the location within a session varies.
Suggested behaviour
- Prefer the platform-standard location (~/Library/Developer/Xcode/DerivedData) as other CLI coding agents do (Claude Code and Codex CLI don't redirect xcodebuild output), so existing Xcode tooling and cleaners manage it; or
- if session isolation is required, use a documented, dedicated cache location (e.g. ~/Library/Caches/ on macOS, marked as excluded from Time Machine) with automatic cleanup — deleted when the session ends or is pruned, and/or subject to a retention/size cap.
- At minimum, document that derived data is stored under session-state and that /session prune / /session delete is the way to reclaim it.
Environment
- Copilot CLI version: 1.0.70
- OS: macOS 26.5.1
- Xcode: 26.2
Affected version
1.0.70
Steps to reproduce the behavior
- Use Copilot CLI in an iOS/macOS project and ask it to build or run tests.
- Inspect ~/.copilot/session-state//files/ — derived data appears in one of the layouts above.
- Repeat across sessions/days; the folders are never cleaned up.
Expected behavior
- Prefer the platform-standard location (~/Library/Developer/Xcode/DerivedData) as other CLI coding agents do (Claude Code and Codex CLI don't redirect xcodebuild output), so existing Xcode tooling and cleaners manage it; or
- if session isolation is required, use a documented, dedicated cache location (e.g. ~/Library/Caches/ on macOS, marked as excluded from Time Machine) with automatic cleanup — deleted when the session ends or is pruned, and/or subject to a retention/size cap. Or a temporary location like /tmp/build.
- At minimum, document that derived data is stored under session-state and that /session prune / /session delete is the way to reclaim it.
Additional context
No response
Describe the bug
When Copilot CLI builds or tests Xcode projects, it writes Xcode derived data inside its own session-state directory rather than the standard Xcode location. I've found it in two layouts:
These contain the usual derived data content (Build/, CompilationCache.noindex/, SourcePackages/, ModuleCache.noindex/, Info.plist, etc.). On my machine a single session's DerivedData folder had grown to over 20 GB. And I had instances of both paths listed above, so 40GB+ used by stale Copilot sessions.
Why this is a problem
Suggested behaviour
Environment
Affected version
1.0.70
Steps to reproduce the behavior
Expected behavior
Additional context
No response