C: Drive Purging Plan

Consolidated from Core/_WorkingOn/Later/HD Purging.md (original dated 2026-02-06-ish).

Executed 2026-07-21: C: went from 7.9GB → 19.18GB free (Talbot approved all items via task file). See per-item results below; two items remain — Chrome cache and kopia relocation — flagged for a separate small decision rather than auto-executed.

Context

• Drive: 240 GB SSD (C:)
• Goal: 50+ GB free for comfortable WSL development
• Baseline: Windows + apps ~150-170 GB, leaving 70-90 GB working space

Immediate actions

• WSL crash dumps — checked: already 0GB (nothing to clear)
• Empty Recycle Bin — Talbot confirmed already <3MB, skipped as unnecessary
• User Temp folder — ✅ done 2026-07-21: cleared, 0.86GB → 0.08GB remaining (some files locked/in-use, skipped silently by -ErrorAction SilentlyContinue)

Medium priority

• .gemini folder — ✅ done 2026-07-21: removed, 6.1GB recovered (Talbot: rebuilds automatically on next Gemini use)
• Chrome cache — checked via chrome://settings/clearBrowserData: only ~200MB. Talbot decided not worth clearing — closed, no action.
• Playwright browsers — Talbot confirmed in use, skipped

Lower priority — review & decide

• AI IDE caches — ✅ done 2026-07-21: .windsurf (2.49GB), .codeium (1.07GB), .trae (1.07GB) removed per Talbot (“no longer use”). .vscode and .cursor left untouched (still in use).
• C:\xfer\bak (was 4.8 GB) — no decision from Talbot yet, left alone
  • purged to 90MB
• kopia cache (11.83GB) — ✅ done via my_backup-kopia-cache-relocation (its own my_backup task, since it touches the live backup pipeline) — ~12GB freed

Result

C: free space: 7.9GB → 52GB (2026-07-21, after Talbot’s own additional app purge) — Temp + .gemini + .windsurf/.codeium/.trae + C:\xfer\bak + kopia relocation + Talbot’s manual app cleanup, combined. Well clear of the diskcheck 20GB threshold; diskcheck itself confirmed working (see LESSONS.md).

Regular maintenance — ✅ scheduled 2026-07-21

Talbot’s right that 30GB doesn’t stay 30GB — this was in the plan but never actually executed. Fixed:

• Script: D:\FSS\Software\Utils\Windows\cleanup-c-drive.ps1 (temp + wsl-crashes cleanup, warns if <20GB free after running) — originally written to C:\Scripts\, relocated per Talbot’s correction (2026-07-21); see feedback-utility-script-placement convention, now in ai-config/AGENTS.md

• Scheduled task registered: MonthlyDriveCleanup — weekly Sunday 9:30am (tighter than monthly; harmless to run more often since it only touches temp files >7 days old), RunLevel: Limited (no elevation — learned from the diskcheck mistake, full path used from the start)

• Verified via actual trigger (not just “registered without error”): Start-ScheduledTask → LastTaskResult: 0 — re-verified again after the relocation

• Windows Disk Cleanup / component store: not automated — cleanmgr /d C /sageset:1 + /sagerun:1 needs one-time interactive configuration (the /sageset dialog). Talbot to run once; after that it could be added to the scheduled script.

• Compact WSL virtual disk — found something bigger than expected: the WSL disk (ext4.vhdx) is 52.99GB on C:, of which WSL itself only reports 44GB actually used — meaning ~9GB is reclaimable slack from a VHDX that’s never been compacted (grows on write, doesn’t auto-shrink on delete). Why this isn’t automated: compaction requires wsl --shutdown, which terminates every running WSL instance — including whatever’s driving an active session (this one, or any other open WSL terminal/Claude Code session). There’s no safe “on startup” hook for this: the operation is inherently an offline one (WSL must be stopped to touch its own disk file), so it can only run when nothing is using WSL — which an automated trigger can’t reliably guarantee without risking an interrupted session. Better fix than repeat manual compaction: wsl --manage Ubuntu-24.04 --set-sparse true (run once, after wsl --shutdown) converts the VHDX to a sparse file — Windows then reclaims space automatically as WSL deletes files going forward, largely eliminating the need to repeat this. One-time manual run, not an ongoing automation. Handed to Talbot, see Next Steps.

Preventive — .wslconfig

Not applied — flagging a conflict before touching this. No .wslconfig currently exists, which means WSL is using its default memory cap (~50% of host RAM, ~15GB observed) — not literally “uncapped,” but a reasonable default. The Slow Computer.md lesson (2026-02-06, now in LESSONS.md) explicitly notes WSL was deliberately left uncapped for dev work. The purge-plan’s suggested memory=8GB would be a real cut from the current ~15GB default, not a neutral cleanup — could pinch heavy dev workloads (Docker, big builds). Recommend confirming you actually want that trade-off before I apply it, rather than assuming the old note’s suggestion still reflects what you want today.

Dev practices: pnpm exclusively (done), pnpm store prune, sudo apt autoremove && sudo apt clean in WSL.

Quick diagnostics

[math]::Round((Get-PSDrive C).Free / 1GB, 2)

Get-ChildItem "$env:LOCALAPPDATA" -Directory | ForEach-Object {
    $size = (Get-ChildItem $_.FullName -Recurse -Force -EA 0 | Measure-Object Length -Sum).Sum
    [PSCustomObject]@{ Folder = $_.Name; SizeGB = [math]::Round($size/1GB, 2) }
} | Sort-Object SizeGB -Descending | Select-Object -First 10

Get-ChildItem "$env:LOCALAPPDATA\Packages\*Ubuntu*\LocalState\*.vhdx" |
    Select-Object Name, @{N='SizeGB';E={[math]::Round($_.Length/1GB, 2)}}

HD Purging note supersession

This file supersedes Core/_WorkingOn/Later/HD Purging.md — that note has been deleted (content fully migrated here, migrate-then-delete per SSOT).