fix(windows): never run in session 0 — skip LaunchApp on silent installs + in-app guard

[BrianLeishman]

Summary

• Root cause of the fleet-wide "storage links silently do nothing" reports (StirlingMarketingGroup/StirlingMarketingGroup#7436): GPO machine-context installs run msiexec silently as SYSTEM in session 0 at boot, and the LaunchApp custom action fired there too. The explorer.exe handoff (fix(windows): survive wrong-identity installs — de-elevated MSI launch + access-denied Explorer fallback #5) doesn't help in session 0 — there's no shell, so explorer just runs the exe itself. The resulting copy is worse than not running at all: it binds 127.0.0.1:29101 and answers /status (clients think it's healthy), but every Explorer window it opens lands on session 0's invisible desktop, and it blocks the user's logon copy from binding the port. Confirmed in the field: tasklist /v showed folder-opener.exe with Session Name: Services, Session# 0, User Name: N/A on an affected machine.
• Why it looked intermittent ("50/50"): LaunchApp only fires during an install/upgrade, so only boots that applied a new MSI version spawn the squatter — the machine stays broken until its next plain reboot, then heals, then re-breaks on the next version rollout. The rapid 0.2.1→0.2.3 release run kept a rotating chunk of the fleet inside the broken window.

Changes

MSI (packaging/windows/folder-opener.wxs)

• LaunchApp now requires UILevel >= 4: silent installs (GPO = UILevel 2) never launch during install and rely on the existing HKLM Run value at each user's next logon — the same behavior Dazzle's MSI has always had (it never had a launch action, which is why it never hit this). Interactive double-click installs keep the instant launch, still via the explorer.exe handoff from fix(windows): survive wrong-identity installs — de-elevated MSI launch + access-denied Explorer fallback #5.
• Comment rewritten — the old "GPO install is a no-op for LaunchApp" claim was exactly wrong.

Server (main.go, session_windows.go, session_other.go)

• Exits at startup when running in session 0 (ProcessIdToSessionId), before binding the port, so a wrongly launched copy can never squat the port or swallow opens — defense in depth if anything else (a service context, future packaging changes) ever launches it there. No-op stub on non-Windows.

Rollout

Tag the next release and let GPO apply it: the upgrade's existing CloseApplication kills any squatting session-0 copy at boot, the conditioned LaunchApp doesn't respawn it, and the Run key starts a proper per-user copy at logon. Every currently-broken machine self-heals with zero manual steps. (Immediate per-machine triage without waiting: elevated taskkill /f /im folder-opener.exe, then start it from the Start menu.)

Test Plan

• go build ./... && go vet ./... && go test ./...
• GOOS=windows go build -o /dev/null . and GOOS=linux CGO_ENABLED=0 go build -o /dev/null .
• Build the MSI, install via msiexec /i folder-opener.msi /qn from an elevated prompt: no folder-opener.exe process appears; after logoff/logon it runs in the user session with the tray icon
• Interactive double-click install: launches immediately as the desktop user (unchanged)
• Manually start the exe via a SYSTEM session-0 shell (psexec -s -i 0): it exits immediately with the session-0 log line

🤖 Generated with Claude Code