Warp Group Container 1TB On Mac: Safe Storage Triage

If macOS System Data jumps by hundreds of gigabytes and ~/Library/Group Containers/2BBY89MBSN.dev.warp is the largest folder, capture child-path evidence before deleting the whole container.

Why This Looks Like System Data

macOS often reports large app containers, caches, databases, indexes, and local app state as System Data. That means the Storage UI can show a huge vague number while the actual culprit is a specific app-owned folder.

~/Library/Group Containers/2BBY89MBSN.dev.warp

Collect The Useful Evidence First

The top-level folder size proves Warp is involved, but the fix depends on which child path is growing: a SQLite database, WAL file, codebase index, cache, session history, or another persisted data class.

ROOT="$HOME/Library/Group Containers/2BBY89MBSN.dev.warp"
du -h -d 1 "$ROOT" 2>/dev/null | sort -h | tail -40
du -h -d 2 "$ROOT" 2>/dev/null | sort -h | tail -80
find "$ROOT" -type f -size +1G -print0 2>/dev/null |
  xargs -0 ls -lh 2>/dev/null |
  sort -k5 -h |
  tail -40

Do not paste private file contents into a public issue. Path names, sizes, timestamps, and redacted child-folder names are enough for triage.

Risk Buckets

• Usually safe to inspect: folder sizes, large-file list, timestamps, and whether the app is currently open.
• Review first: app databases, WAL files, indexes, session state, codebase metadata, and local history.
• Do not delete blindly: the entire group container while Warp is open, unless you accept resetting Warp local data.

Safer Recovery Order

1. Quit Warp completely.
2. Capture the child-path size breakdown.
3. Move the whole group container to a dated backup folder if the Mac is blocked and you need emergency space.
4. Reopen Warp and confirm whether the issue returns.
5. Delete the backup only after you know which local data you are giving up.

mv "$HOME/Library/Group Containers/2BBY89MBSN.dev.warp" \
  "$HOME/Desktop/Warp-group-container-backup-$(date +%Y%m%d-%H%M%S)"