Summary
Start-VSCodeDrive mints a uniquely-named user-data dir per launch, and Stop-VSCodeDrive deletes it. The happy path is correct. But when a run never reaches teardown — agent interruption, crash, killed session, an exception between start and stop — the dir is orphaned and nothing ever reclaims it.
Found while reclaiming disk space on a dev machine: 21 orphaned .drive-udd-* dirs, 10–30 days old, in .github/skills/vsce-testing/.
Evidence
scripts/vscode-drive.psm1:
# L166 - new dir per launch
$udd = Join-Path $harness (".drive-udd-" + [guid]::NewGuid().ToString('N').Substring(0, 8))
# L516 - cleaned ONLY via Stop-VSCodeDrive
Remove-Item $Ctx.Udd -Recurse -Force -ErrorAction SilentlyContinueThere is no sweep at start, and no try/finally guaranteeing teardown, so the cleanup is reachable only on the path that completes normally.
Impact
Low severity, unbounded growth. The 21 orphans totalled ~50 MB, but two of them were ~22 MB each — size depends on how far the VS Code instance got before dying, so a run that loaded the C# extension leaves a much bigger dir. On a machine running this skill regularly it grows without limit, and it is invisible because the dirs are gitignored (.gitignore:4).
Suggested fix
Defensive sweep in Start-VSCodeDrive: before creating the new dir, remove any existing .drive-udd-* in the harness whose leaf name does not appear in the command line of a live process. The liveness check already exists — Get-VSCodeWindow (L218) and Stop-VSCodeDrive (L513) both match CommandLine against the udd leaf, so the same predicate can be reused. That makes cleanup self-healing without risking a dir belonging to a concurrently running instance.
Worth pairing with a try/finally around the drive lifecycle so normal exceptions still hit teardown.
Notes
- Pre-existing on
main; unrelated to any open PR.
- The
.drive-extensions/ dir is a different case and should not be swept — it is an intentional cross-run cache of installed extensions.
Summary
Start-VSCodeDrivemints a uniquely-named user-data dir per launch, andStop-VSCodeDrivedeletes it. The happy path is correct. But when a run never reaches teardown — agent interruption, crash, killed session, an exception between start and stop — the dir is orphaned and nothing ever reclaims it.Found while reclaiming disk space on a dev machine: 21 orphaned
.drive-udd-*dirs, 10–30 days old, in.github/skills/vsce-testing/.Evidence
scripts/vscode-drive.psm1:There is no sweep at start, and no
try/finallyguaranteeing teardown, so the cleanup is reachable only on the path that completes normally.Impact
Low severity, unbounded growth. The 21 orphans totalled ~50 MB, but two of them were ~22 MB each — size depends on how far the VS Code instance got before dying, so a run that loaded the C# extension leaves a much bigger dir. On a machine running this skill regularly it grows without limit, and it is invisible because the dirs are gitignored (
.gitignore:4).Suggested fix
Defensive sweep in
Start-VSCodeDrive: before creating the new dir, remove any existing.drive-udd-*in the harness whose leaf name does not appear in the command line of a live process. The liveness check already exists —Get-VSCodeWindow(L218) andStop-VSCodeDrive(L513) both matchCommandLineagainst the udd leaf, so the same predicate can be reused. That makes cleanup self-healing without risking a dir belonging to a concurrently running instance.Worth pairing with a
try/finallyaround the drive lifecycle so normal exceptions still hit teardown.Notes
main; unrelated to any open PR..drive-extensions/dir is a different case and should not be swept — it is an intentional cross-run cache of installed extensions.