**What happened:** After using the Windows VM's Samba-based `/shared` folder once, every subsequent `omarchy-windows-vm launch` fails with only:
```
❌ Failed to start Windows VM!
   Try checking: omarchy-windows-vm status
```
No further diagnostic is printed anywhere (not in the terminal, not in `journalctl`), making this very hard to diagnose.

**Root cause:** While the VM runs, its Samba share loosens the permissions on the host `~/Windows` bind-mount source (observed at `2777` while the container was up). On the next launch, `prepare_caller_mounts()` tries to re-harden it back to `700`:

```
583:  chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
...
590:  if [[ $storage_mode != 700 || $shared_mode != 700 ]]; then
```

This `chmod` invocation reliably clears the regular permission bits but **not the setgid bit**: mode goes from `2777` → `2700`, never to plain `700`. Reproduced directly:

```
$ chmod -v 0700 /home/aya/Windows
mode of '/home/aya/Windows' retained as 2700 (rwx--S---)
```
vs. the same target chmod'd with a symbolic mode (`chmod g-s`) or a raw `os.chmod()` syscall, which clears it correctly to `700` every time. Filesystem is btrfs (`/home` subvolume).

Since the check on line 590 requires an exact `700`, it fails every time after the Shared folder has been used, and `launch_windows()` swallows the failure with the generic message above.

**Note for anyone patching locally:** Omarchy ships two copies of this script — `/usr/bin/omarchy-windows-vm` and `/usr/share/omarchy/bin/omarchy-windows-vm` — both owned by the `omarchy` package and normally byte-identical. `priv_target()` hardcodes `/usr/bin/omarchy-windows-vm` as the only trusted target for the privileged (`pkexec`) bring-up, so that copy is what actually runs regardless of which one is edited. **The fix must be applied to `/usr/bin/omarchy-windows-vm`** (and ideally mirrored to the `/usr/share/omarchy/bin` copy to keep them in sync) or it will appear not to work.

**Confirmed fix:** Adding a symbolic `chmod u-s,g-s` immediately after the existing numeric `chmod 0700` reliably clears the bit. Tested end-to-end against `/usr/bin/omarchy-windows-vm`: deliberately set `~/Windows` to `2777` (reproducing the post-Samba state), ran a real `omarchy-windows-vm launch`, and the container started successfully with the folder correctly hardened to `700`.

```diff
   # Privacy is an explicit preflight step for both already-pinned sources, not
   # a side effect halfway through the two-mount transaction. Old umask-022
   # installs are hardened together before either Docker-facing anchor changes.
-  chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
+  chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" &&
+    chmod u-s,g-s -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
     exec {storage_fd}<&-
     exec {shared_fd}<&-
     return 1
   }
```
(apply to both `/usr/bin/omarchy-windows-vm` and `/usr/share/omarchy/bin/omarchy-windows-vm`)

**Steps to reproduce:**
1. Install and launch the Windows VM (`omarchy-windows-vm install` / `launch`).
2. Use the RDP session so the VM's Shared folder gets accessed (or just check `stat -c %a ~/Windows` after the container is `Up`; it becomes `2777`).
3. Close RDP / stop the VM.
4. Run `omarchy-windows-vm launch` again → fails with no explanation.
5. Workaround without the patch: `chmod g-s ~/Windows` then relaunch — works until the VM's Shared folder is used again.

**System:** Arch Linux, `omarchy 4.0.4-1`, Docker 29.7.2, `dockurr/windows` image, btrfs `/home`.

Filed by Claude Sonnet 5 via Claude Code.