~/.husk is created by doctor that says it is not, and deleting it does not reset husk on WSL

[Hotragn]

Two separate things, both about ~/.husk not being what it says it is. Filing together
because the fix is one pass over the same story.

1. doctor prints "not created yet" and then creates it

$ ls -la ~/.husk
ls: cannot access '.husk': No such file or directory

$ npx -y @husk-ai/cli doctor
husk 0.1.3  node 24.14.0 · win32-arm64
state: C:\Users\hotra\.husk  (not created yet)
...

$ ls -la ~/.husk
drwxr-xr-x cache/  computers/  data/  husks/  runs/  transcripts/  workspaces/

Seven directories, all timestamped at that run, and no other command had been run. So the
line is true when it is printed and false by the time the command exits.

The README is more specific than the line is: "Nothing is created until the first tool
call, so an installed husk that nobody uses costs nothing." doctor is not a tool call.
Someone who runs doctor to decide whether to keep husk has already been given a state
directory.

The cost is seven empty directories, so this is cosmetic in effect. It is in the honesty
surface, though, which is the part of husk I would least want to be loose.

While in there: ~/.husk/cache/ was empty after doctor, so provider probes are not
cached across invocations. That is consistent with
probeTtlMs = 30_000
being per-process, and with how the homepage phrases it ("an agent that creates four
machines in a row pays that once"). But a reader can easily take "provider probes are
cached for 30 seconds" to mean two husk commands in a row are cheap, and they are not.
Either the sentence or the cache should move.

2. "delete it to reset husk completely" is not true on WSL

The first-run banner:

  state      C:\Users\hotra\.husk (delete it to reset husk completely)

On the WSL path the workspaces live in the WSL home, which that directory does not
contain. The computer record says so itself:

"nativeId": "\\\\wsl.localhost\\Ubuntu\\home\\hotragn\\.husk\\workspaces\\cmp_2p6pgx38a4gt",
"husk.wslWorkspace": "/home/hotragn/.husk/workspaces/cmp_2p6pgx38a4gt"

~/.husk/workspaces/ on the Windows side stayed empty for the whole session.

I found this by moving ~/.husk aside to get a clean first run. It was not clean. Three
workspaces from earlier sessions were still inside WSL, and the ~/.husk I moved aside
held exactly one computer record:

$ wsl -d Ubuntu -e bash -lc "ls -1 ~/.husk/workspaces/"
cmp_12rgq756hr3g      # no record on the Windows side
cmp_2p6pgx38a4gt      # mine, this session
cmp_gfevmyp99fg5      # mine, this session
cmp_hqwka5hzb325      # the one record that existed
cmp_y1d5a7x4qnc2      # no record on the Windows side

So two were already orphaned before I started. Nothing I did created them; normal use
did.

Deleting ~/.husk deletes the bookkeeping and leaves the data, which is the wrong half to
keep. It also means "reset husk completely" leaves a machine's files on disk, which for a
tool whose pitch includes /work outliving the conversation is a surprising thing to get
backwards.

What I would do

For (1), print the line after the directory exists, or do not create it in doctor — the
second matches the README.

For (2), the banner should say what it actually covers, and husk needs some way to see
and clear WSL-side workspaces whose record is gone. LocalProvider already has the
orphan scan (local.ts around 862-895) and the comment there notes it reports rather than
sweeps, with the registry entry as the anchor. Surfacing that in doctor would have told
me about those two orphans instead of leaving me to find them with ls.

[Hotragn]

A third one for the same pile, found while tearing down the test machines rather than
during the pass itself. It starts small and does not stay small, so the second half is
probably its own issue.

The small half: husk rm <name> leaves the binding

$ husk rm cmp_r8cqtrfad0ed --yes
destroying mcp-mcp...
✓ destroyed mcp-mcp

$ cat ~/.husk/computers/bindings.json
{
  "mcp": "cmp_r8cqtrfad0ed"
}

The record and the workspace are both properly gone — I checked the WSL side before and
after rather than trusting the tick. Only the binding survives.

This one is genuinely minor, because ensure() self-heals. manager.ts:191-196 reads the
binding, finds no computer or a destroyed one, clears it and creates a fresh machine. The
next session on that key works and the stale entry disappears. Dangling state with a short
life, not a broken session.

The cause, which is shared

rm.ts:89
destroys the Computer directly:

await computer.destroy();

That bypasses
ComputerManager.destroy(id),
which does two things first:

const key = c.info.spec.labels?.['husk.key'];
// Before the machine goes, not after: a browser's `close()` runs a `pkill`
// *inside* the computer, which only works while the computer still exists.
await notifyComputerDestroyed(id);
await c.destroy();
if (key) await clearBinding(key);

husk rm --all routes through mgr.destroyAll(). The single-target path does not, so the
two rm paths disagree about what destroying a computer includes.

The half that is not minor

notifyComputerDestroyed has exactly one caller in the tree —
manager.ts:257
— and rm.ts does not reference it. So husk rm <name> skips the destroy hook entirely,
and the only subscriber to that hook is the browser
(session.ts:367).

lifecycle.ts is unusually clear about what that hook is for:

The leak this exists to close: a browser session outlives its computer. [...] nothing
called close() when the computer was destroyed. [...] So every machine that ever
opened a page left a browser running: measured, 23 headless_shell processes still
alive the next day, each holding its workspace directory open so husk rm could not
delete it and ~325 MB per machine stayed on disk.

On the husk rm <name> path that leak looks open again. And the tell is inside rm.ts
itself — the error it raises when destroy fails:

hint: 'something may still hold the workspace open — close it and retry, or delete it by hand',

That hint describes the exact symptom the hook was written to prevent, in the one function
that does not call the hook.

What I have and have not verified

Verified by reading, and not really arguable: notifyComputerDestroyed has one caller,
rm.ts is not it, and the browser is the only subscriber.

Not reproduced. I never exercised the browser_* tools this pass, so I have not
watched a headless_shell survive a husk rm. Someone should open a page, husk rm the
machine, and check for a surviving process and a surviving workspace before treating the
leak as confirmed. The call graph says it should survive; I am not claiming I saw it.

Fix

Routing the single-target path through mgr.destroy(id) fixes the binding and the hook
together, and makes the two rm paths agree. Worth a test that asserts the hook fired,
since the failure mode here was silence — same shape as #86, where a missing method
produced output identical to "swept, found nothing".

Happy for the browser half to be split out; it is a different severity from the two
state-directory items in this issue.

[Hotragn]

The docker analogue of the WSL workspaces above: husk rm removes the container and
leaves the volume.

After destroying every husk computer on this machine, docker ps -a was clean and four
volumes were not:

$ docker ps -a --filter "label=husk.provider=docker" --format '{{.Names}}'
  (none)

$ docker volume ls --format '{{.Name}}' | grep husk
husk-key-hinttest-1vj7n24
husk-key-mcp-1kiasf7
husk-key-reaptest-0bqavoh
husk-key-verify-1789288929771-1gkp955

These are the persist: true volumes ensure(key) creates, named husk-key-<key>-<hash>.
Three of them (hinttest, reaptest, verify-1789288929771) are from sessions well before
mine, so this accumulates in normal use the same way the WSL workspaces do.

The persistence itself is working exactly as designed, and worth recording as a win rather
than only a leak: a fresh MCP session re-attached to husk-key-mcp-1kiasf7 and found files
dated five days earlier, including the .husk-browser profile that lifecycle.ts says used
to die with tmpfs containers. /work survived several container removals and multiple days.
That is the claim holding.

The gap is only reclamation:

• husk rm <name> destroys the container; the volume stays.
• husk ls lists computers, so a volume with no container is invisible to husk.
• There is no husk command that lists or prunes them, so the only way to find them is
  docker volume ls, which means knowing to look.

I have not checked whether the reaper reclaims them — I never got husk serve up this pass,
so that is untested. If reap() only destroys computers, the volumes outlive the reaper
too.

Worth noting the naming makes a prune safe to write: the husk-key- prefix plus the key is
enough to tell whether a volume has a live binding in bindings.json, which is the same
file the dangling-binding half of this issue is about. A husk prune that removed
husk-key-* volumes with no binding and no container would close both halves at once — and
would need to be careful that a volume whose binding is stale for the reason described above
is not treated as garbage while its session is still live.