## What happened

`omarchy-windows-vm launch` (and `omarchy-windows-vm remove`) fail with a generic error — `❌ Failed to start Windows VM!` / `❌ Windows VM removal stopped before user-side cleanup; inspect the VM data before retrying.` — even when Docker, the compose file, and the VM's own data are all perfectly healthy. No Docker/QEMU activity happens at all when this triggers (confirmed via `journalctl -t dockerd`: zero new log lines across five failed `launch`/`remove` attempts).

### Root cause

`omarchy-windows-vm`'s mount-safety check `mounted_leaf_matches()` requires the shared-folder bind-mount anchor to be **exactly** mode `700`:

```bash
mode=$(stat -Lc '%a' "$stable" 2>/dev/null) || return 1
...
[[ $actual == "$identity" && $owner == "$CALLER_UID" && $mode == 700 ]]
```

But the `dockurr/windows` container re-applies the **setgid bit** to the host `/shared` bind-mount source (`~/Windows`) as part of its own entrypoint/provisioning, turning the directory's mode from `700` into `2700`. Since the anchor is a bind mount, this change is visible on the host immediately.

The very next privileged action (`up`, `up_wait`, or `remove`) calls `assert_mounts_safe` → `mounts_ready` → `mounted_leaf_matches`, sees `2700 != 700`, and fails **before ever calling `dc up -d` / `dc down`** — which is why nothing shows up in the Docker logs and the error message gives no actionable detail. This affects both starting the VM again and removing it: `__priv_remove` calls the exact same `assert_mounts_safe` check first, so removal is blocked identically (and looked, at first, like it might be silently destructive/stuck — it isn't, it's just refusing early, but the error message doesn't say why).

`~/.windows` (the `/storage` mount) does **not** exhibit this — only `~/Windows` (the `/shared` mount) does, which lines up with the shared folder being the one the container's own provisioning writes group-shared permissions onto.

## Expected behavior

- `omarchy-windows-vm launch` should be able to reconnect to (or restart) a VM it just successfully started, without a manual permission fix in between.
- Either `mounted_leaf_matches`/`prepare_caller_mounts` should re-normalize the anchor's mode (chmod 0700) as a self-healing step even when the mount already exists, rather than only checking-and-refusing, or the check itself needs to tolerate/strip the setgid bit that the container adds back.
- At minimum, the error message should say *why* it's refusing (e.g. "shared mount anchor has unexpected mode 2700, expected 700") instead of the generic "Failed to start Windows VM!" / "removal stopped before user-side cleanup" — this took extensive log/permission archaeology to diagnose.

## Steps to reproduce

1. `omarchy-windows-vm install` (defaults are fine).
2. `omarchy-windows-vm launch` — installs/boots successfully the first time.
3. Let the VM fully start (or let it shut itself down after first-boot provisioning, which `dockurr/windows` does normally).
4. `stat -c '%a' ~/Windows` → now reports `2700` instead of `700` (was `700` before step 2).
5. `omarchy-windows-vm launch` again (or `omarchy-windows-vm remove`) → fails immediately with no Docker activity in `journalctl -t dockerd`.
6. Manually `chmod 0700 ~/Windows` and retry → works once, then the container flips it back to `2700` on its next start and the cycle repeats.

## System details

- Omarchy: `4.0.2-1`
- Kernel: `7.1.9-arch1-2`
- Docker: `29.7.2` (build a7dcaa6fdb)
- Docker Compose: `5.5.0`
- Filesystem: btrfs (`/home` on `@home` subvolume)
- VM image: `dockurr/windows:latest` (digest `sha256:0cff9eb0e7aee9953e55bc682852ca4fdca233145a58ae1ec94f0b0c01a2ed30`)

Full `omarchy-debug --no-sudo --print` output available on request (908 lines, trimmed here for brevity).

---
🤖 Filed with the help of [Claude Code](https://claude.com/claude-code)