Handoff — battlebox C: reclamation + WSL rebuild on D:

2026-07-30 12:01 JST · for the next agent session · machine: battlebox (Windows, Czech Republic, VPN-only)

Summary

Continuation target: finish reclaiming space on battlebox's C: drive, then replace the ancient WSL Ubuntu 20.04 (241.8 GB VHDX on C:) with a fresh Ubuntu 26.04 installed on D:, and unregister the old distro.

C: free went 1.5 GB → 42.06 GB this session. About 171 GB more is identified but not yet authorised, and the WSL rebuild returns a further 242 GB.

Running this on battlebox itself

Miro is considering running the next session natively on battlebox rather than over ssh from Battlebook. That is a good instinct — but three things need deciding first.

Blocker Claude Code is not installed in battlebox's WSL. The inventory found claude → absent, codex → absent. Only cursor-agent 2026.07.13 is present. So "run it on battlebox" needs a runner decision before anything else.

An agent living inside the old 20.04 distro cannot be the one to retire it. wsl --unregister Ubuntu would terminate its own host mid-command. Same applies to wsl --shutdown.

Runner options

Option	Fits?	Notes
`codex-bb` wrapper (Windows `codex.exe` on battlebox)	Best	Runs on the Windows side, outside WSL — survives the whole rebuild including the unregister. Skill: `codex-bb-runtime`, agent: `codex-bb-delegate`. Already set up.
`cursor-agent` in the old WSL	Partial	Already installed, fine for the repo cleanup and data copy, but it lives inside the distro being retired. Hand distro-level ops elsewhere.
Install Claude Code in the new 26.04 distro	Good, later	Natural once step 2 is done — the new distro then finishes its own setup. Don't install it into the old one; that just adds to the disk you're deleting.
Plain `ssh battlebox` from Battlebook	Fallback	What this session used. Works, but carries the VPN-drop risk below.

The real win of going on-box: it removes the VPN-drop risk. The link to Czechia is latent, and a dropped ssh session mid-copy or mid---install is the main operational hazard in the remote path. Running locally makes long operations safe to run in the foreground.

Recommended shape: drive distro-level operations (wsl --install, --shutdown, --unregister, the PowerShell disk cleanup) from the Windows side; do the WSL-internal work (git cleanup, data copy, uv sync) from inside a distro. Never let one distro command its own destruction.

If you do stay on the remote ssh path — quoting traps that cost this session two failed calls

ssh battlebox "... $_ ..." is mangled by the local bash before it ever reaches Windows ($_ expanded to unsetenv). Write PowerShell to a local temp file, copy it, run it:

cat > /tmp/x.ps1 <<'PSEOF'
...
PSEOF
scp -q /tmp/x.ps1 battlebox:x.ps1 && ssh battlebox "powershell -NoProfile -ExecutionPolicy Bypass -File x.ps1"

ssh battlebox "bash -s" <<'EOF' works for WSL, but never use sudo inside it — the password prompt hangs the session until timeout. This happened once; the du had to be re-run without sudo.

Always -NoProfile for PowerShell — the profile loads a broken conda hook.

Housekeeping: eight scratch scripts were left in battlebox's Windows home — bb-disk.ps1, bb-wsl.ps1, bb-users.ps1, bb-more.ps1, bb-cad.ps1, bb-del.ps1, bb-temp.ps1, bb-rb.ps1. Delete them when done.

Current state

C: 931 GB total, 42.06 GB free (was 1.5 GB at session start). D: 3.7 TB, ~744 GB free. Both NVMe SSD — C: Samsung 980 PRO 1TB, D: Samsung 990 EVO Plus 4TB. Moving to D: costs no speed.

Done complete

Deleted	Freed
`C:\Users\cad\Downloads\` — Vectorworks 2021 SP5 / 2022 SP2 / 2023 SP3 (dirs + `.exe` + `.zip`) and ARCHICAD 24 + 25 installers, 7 items	28.4 GB
`C:\Users\ai\AppData\Local\Temp`	12.7 GB
`ai` user recycle bin	0 GB (already empty)

Identified but NOT authorised ask first

Miro has been approving these one at a time. Do not batch-delete.

Item	Size	Note
`C:\Autodesk`	66.8 GB	Extracted Revit/Plant3D installer cache; Autodesk re-downloads on demand
`C:\Users\cad\Downloads\download_2022-05-19_11-23-16.zip`	54.9 GB	Untouched since 2022, opaque name. Offered as "move to D: or delete" — Miro answered neither
`C:\Users\br\AppData\Local\Google\DriveFS\...\content_cache`	29 GB	3 files alone = 25 GB; re-syncs. `D:\GDrave_Cache` already exists, so the redirect pattern is established on this box — `br`'s account just isn't using it
`C:\Users\cad\Downloads\Autodesk\`	9.5 GB	Most recent of the cad downloads (2025-08-27)
`C:\Users\br\...\NVIDIA Corporation\NvNode\nvnode.log`	6.8 GB	A single log file
`br` user recycle bin	4.6 GB	Explicitly left alone — Miro authorised the `ai` bin only
Trimble Nova 16.2/16.3 + FME 2022 installers in `cad\Downloads`	3.8 GB

Full C: top-level breakdown (for re-reference without re-scanning — the scan takes ~10 min)

Program Files 140.4 · Windows 89.8 · ProgramData 44.8 · Program Files (x86) 30.2 · C:\Programs 24.8 · C:\dev 15.4 · C:\Users\ai\data\randomizedAnnotations 13.9 · ai's DriveFS 13.9 · C:\Internal 10.3 · pagefile 8.0 · FME 6.2 · WorkDump 5.8 (all GB).

Per-user: ai 310.6 · cad 111.5 · br 46.9 · All Users 44.8 · oc 13.1 · ps 3.4 · ml 1.0.

Note C:\Documents and Settings is a junction to C:\Users — it is double-counted in any naive recursive scan. Use -Attributes !ReparsePoint.

Blocker — clear this before anything destructive

13 repos under /home/ai/dev have uncommitted or unpushed work. This is the only irreversible risk in the whole operation. Miro's last exchange left him about to receive a per-repo report of what is dirty vs unpushed so he can decide push vs discard. Start here.

Repo (under `~/dev/`)	dirty	unpushed
pytorchinstancesegmentation	60	0
3dai.iolabs.pointcloud.guardrails	28	0
3dai.iolabs.pointcloud.visualizationoverlays	12	0
windowchecker	8	0
3dai.iolabs.pointcloud.trajectoryfilter	6	0
pdfpropertyai	4	0
3dai.lanefinder	3	0
3dai.iolabs.imageanalyzer.linebitmapimagerasterizer	3	1
3dai.iolabs.orchestrator	1	0
3dai.iolabs.pointcloud.3dsegmentation	1	0
3dai.iolabs.pointcloud.guardrails-seg3d	1	0
3dai.iolabs.pointcloud.tablecloth	0	9
3dai.iolabs.pointcloud.asphaltedge	0	5

Rebuild plan

Why rebuild, not move the VHDX

Miro originally asked how to move ext4.vhdx to D:. Mid-conversation he proposed a fresh install instead, and that is now the agreed direction. The reasoning, so it isn't re-litigated:

ext4.vhdx is 241.8 GB at C:\Users\ai\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\.
Miro already ran a compaction and it freed almost nothing — that is expected, not a failure. Inside WSL: /dev/sdd 251G, 229G used, 9.2G avail (97%). The guest genuinely holds 229 GB, so there were no deleted-but-still-allocated blocks to reclaim. Do not propose compacting again as a fix.
Distro is Ubuntu 20.04.6 focal — standard support ended April 2025 (ESM only), system python3 is 3.8.10 (EOL Oct 2024), gcc 9.4, git 2.25. A move would just relocate that problem.
Decisive advantage: a fresh install on D: needs zero C: space and runs side-by-side with the old distro, which stays untouched on C: as a live fallback until Miro is satisfied. Better safety property than the move, and it makes the original "back up before moving" concern largely moot.

Version: Ubuntu 26.04 settled

I first recommended 24.04 on a vague "newest LTS has thinner CUDA coverage" heuristic. Miro challenged it; I checked and reversed to 26.04. Don't re-open this without new evidence.

NVIDIA's ubuntu2604/ repo exists and is complete — cuda-nvcc-13-3, cuda-compiler-13-3, cuda-cudart-dev, cuda-libraries-dev, cuDNN/cuBLAS/cuSOLVER/cuFFT, ~800–900 packages, up to CUDA 13.3. (repo listing)
NVIDIA/cuda-samples#417 (opened 9 Apr 2026, still open) captures only the pre-release gap. Several secondhand articles still repeat that stale April state — that is where the "26.04 isn't supported" impression comes from.
Moot for WSL anyway: the CUDA on WSL guide directs you to the generic wsl-ubuntu repo (no distro version in the path) and is emphatic that you must never install a Linux GPU driver inside WSL — libcuda.so is stubbed in from the Windows host driver. That is why the current 20.04 already reports nvidia-smi 590.57.
The real 26.04 caveat is Python 3.14.4 as system interpreter; wheel coverage for open3d / laspy / PDAL / torch may lag. Neutralised by uv — uv python install 3.12 and the system interpreter never enters the venvs.

Verified on the box: wsl --version = 2.7.11.0; wsl --install supports both --location and --name; Ubuntu-26.04 is listed in wsl --list --online.

Sequence

Per-repo dirty/unpushed report → Miro decides push vs discard → clear all 13.

wsl --install Ubuntu-26.04 --location D:\WSL\Ubuntu2604 --name Ubuntu26

Copy dotfiles, keys and data. Fast path: both distros run inside the same WSL2 VM and share /mnt/wsl, so bind-mount the old home there and copy ext4→ext4 at native speed — no 9p/DrvFs penalty.
Re-clone repos, uv sync the venvs, replay the apt manual list.
Verify over a few days of real use.
Cold-archive the old ext4.vhdx to D:\wsl-backup\, then wsl --unregister Ubuntu → +242 GB on C:

Carry-over inventory

The environment is genuinely light — no conda, no Docker, no rust / go / dotnet / java / cmake. Present: uv 0.10.9, nvm with node v24.14.0, cursor-agent 2026.07.13, gcc 9.4, 174 manually-installed apt packages, and 21 .venv dirs under ~/dev — all reproducible from lockfiles, and a large share of that 129 GB.

Must carry: ~/.ssh (contains id_ed25519 and id_ed25519_bitbucket_battlebox plus config), .gitconfig, .claude, .codex, .cursor, .config, .azure, .local, .bashrc, .profile, ~/bashSettings, ~/bin, and the output of apt-mark showmanual.

Non-git data to copy (~60 GB): ai3d339-sweep 26 GB (of which tcs_cache 24 GB is probably regenerable — confirm with Miro), ai3d341_xmlprod 16 GB, tcs-recall 5.9 GB, tcs-wall-exp 3.3 GB, plus phase6, wt-greenness, data, ai3d-*, ai3d346_linewidth, zrange_venv.

WSL disk usage detail

/home/ai = 217 GB · ~/dev 129 GB (linebitmapimagerasterizer alone 63 GB, lanefinder 21 GB) · .npm 11 GB (_cacache 9.5) · .cache 8.2 GB (uv 6.6) · .claude 5 GB (jobs 3.4) · /tmp 6.1 GB · /usr 3.4 GB · /var 1.8 GB.

The new distro should land at 60–100 GB rather than 229 GB, since the venv and cache bloat does not come along.

Cautions

Never "Reset" the Ubuntu Store app in Windows Settings — it re-registers the distro at the default C: location.
Add a Defender exclusion for D:\WSL before the bulk copy, or it crawls and runtime I/O stays slow afterwards.
ssh lands as Windows user battlebox\ai, which is the correct HKCU hive for the Lxss registry keys. Current BasePath confirmed as the LocalState path above.
Only one VHDX exists on C: — there is no Docker WSL disk on this machine, so that is not an available lever.
Other users' profiles (cad, br, oc, ps, ml) live on this box. Touch only what Miro explicitly authorises.
D: free is ~744 GB. A cold archive of the old VHDX (242 GB) plus the new distro still leaves comfortable headroom, but check before assuming.

Artifacts

Vault notes — reference, don't rewrite

In /mnt/c/Users/mirsi/OneDrive/Dokumenty/miro_vault/zettelkasten/ (on Battlebook, not battlebox):

Permanent notes/Mounting a dedicated ext4 VHDX for native-speed WSL2 data on a second drive.md — written 2026-07-19 from an earlier battlebox investigation. Covers wsl --mount --vhd, diskpart VHDX creation without Hyper-V, and the pitfalls. This is the phase-2 follow-up once WSL is on D:.
Permanent notes/WSL2 and Docker VHD compaction.md — the compaction procedure Miro already ran.
Fleeting notes/2026-03-30 C drive disk space analysis.md — this one is about the main desktop, not battlebox. Don't confuse the two.

Miro's daily notes carry two standing open TODOs that this work closes — "Move WSL to D-drive" and "Mount new VHDX on the other drive" — present in daily/2026-07-20.md through 2026-07-28.md.

Worth writing a fresh note once the rebuild lands: the "compaction freed nothing because the guest is genuinely full" diagnosis and the "side-by-side rebuild beats a move" reasoning are both reusable.

Suggested skills

battlebox-ssh — required if driving remotely; still useful on-box for the drive-letter and Google Drive mount conventions (N:/P:/Q: are Windows-side only, no /mnt/n).
codex-bb-runtime — if running on battlebox via the codex-bb wrapper.
cursor-cli-runtime — if using the cursor-agent already installed in the old WSL.
zettelkasten-vault — when writing the outcome up as a note.

Prior markdown handoff from this session (same content, less tailored): /tmp/handoff-LOQQMM.md on Battlebook. Superseded by this page.

Open questions for Miro

Runner: which agent actually executes this on battlebox — codex-bb, the existing cursor-agent, or a Claude Code install in the new distro?
C: deletions: which of the remaining items to remove — especially the 54.9 GB 2022 zip and the 66.8 GB C:\Autodesk cache.
Data: is ai3d339-sweep/tcs_cache (24 GB) regenerable, or must it be copied to the new distro?
Retention: keep the old ext4.vhdx as a cold archive on D: after unregistering, and if so for how long?