Parallel coding agents on Windows break at the home directory, not the launcher

Each of these failures either says nothing or points somewhere else. Redirecting `HOME` alone, a POSIX convention Windows itself does not honor ^[3], moves a CLI's config to the new directory while git carries on writing `.gitconfig` to the old one ^[4], and the first visible symptom, according to the post, is two panes sharing a git identity ^[5]. The set that actually works is `HOME`, `USERPROFILE`, `HOMEDRIVE` and `HOMEPATH` per process ^[6], plus `GEMINI_CLI_HOME` pointed at its own subdirectory for Gemini CLI ^[7]. Five variables to relocate one idea of home ^[1], and nothing errors if you set three of them.

The linking layer has the same property. Full isolation is not the goal, since `CLAUDE.md`, `settings.json` and skills are meant to be identical in every pane, so they get linked back to the global copy instead of duplicated ^[8]. On Windows, `mklink` needs elevation or Developer Mode for a file symlink while junctions need neither, so directories are easy and files fall back to hardlinks ^[9]. A hardlink returns false from `lstat().isSymbolicLink()` ^[10]. Build a "detach this account from shared config" action as "replace symlinks with real copies" and the hardlinked files are skipped: the account goes on editing the global config while the interface reports it detached ^[11]. The author's detection compares device and inode numbers with `bigint: true`, because a plain `ino` comes back as `0` on some Windows configurations, which makes every pair of files look like the same file ^[12]. A comparison tested without that flag would have passed.

Teardown is where the error message actively misdirects. `git worktree remove --force` returns `failed to delete ... Permission denied` ^[13] when the actual cause is that Windows will not delete a directory that is some process's current directory, and git renders that refusal as a permissions error ^[14]. Testing it is worse than reading it. PowerShell's `Set-Location` does not reproduce the failure, because the PowerShell location is a provider concept layered over a process whose real working directory never moved ^[15], so a harness built on `Set-Location` will tell you the bug is imaginary. Killing the shell is not sufficient either: in the author's run the `cmd.exe` was dead and the delete still failed, because the holder was `timeout.exe`, a child that had inherited the directory ^[16]. Any teardown that kills the pane process and then removes the worktree will fail on the first agent that leaves a grandchild running.

For people writing the launcher rather than using one, Node's `os.homedir()` does not reliably reflect a `USERPROFILE` injected at spawn time on Windows ^[18]. The author's project ended up with a dedicated variable for its own storage and a separate function for where a new shell should start, because collapsing the two meant every new terminal opened inside the agent's config directory ^[19].

This is one account, from someone who discloses that he works on a product in this space and marks which decisions are his own ^[20]. It is also the class of detail that only gets written down by someone who has already lost a weekend to it.