[mvilacad]

Three Windows bugs behind "atlas update doesn't work and the CLI doesn't install", all reproduced on a Windows 11 machine.

1. alpha.24's app crashes at launch (release blocker)

failed to create webview: WebView2 error 0x8007139F, on every launch, even with a fresh WebView2 profile. The agent dock (#149, dock.rs) and the capture windows (shots/surface.rs) built their webviews without webview_win::ARGS. WebView2 accepts one set of environment options per process, so the second set killed setup.

• Fix: both builders pass ARGS.
• Guard: every_webview_builder_passes_the_shared_browser_args scans every production webview builder. It fails on the shipped dock.rs (dock.rs:226) and passes with the fix.
• Proof: a release build (tauri build --no-bundle) installed over %LOCALAPPDATA%\Atlas, launched with the real profile: the app is up ("Atlas Dock" window), with no new panic in app.log. The same build without the fix panicked with the same error.

2. atlas update can't replace the app

cannot move …\Atlas aside (is Atlas still running?), so the CLI was rolled back as well. desktop_windows::install_with renamed the whole install folder, and Windows refuses that while any file in it is open. One always is: the bundled atlas.exe running the update, atlas.exe hostd, atlas.exe mcp or the app itself.

• Fix: every entry is renamed aside in place (name.atlas-old-<pid>); Windows allows renaming a running image. Rollback renames back, success deletes them, and an in-use leftover is cleaned by the next run (recover).
• Reopen: the silent NSIS installer terminates a running Atlas Desktop, so it is reopened afterwards. The check matches the installed path, so a dev build with the same image name doesn't count. hostd and the stacks are untouched.
• Test: an_open_file_in_the_install_folder_does_not_block_the_update holds a file open the way Windows holds a running exe. It asserts the folder really is unmovable, so the old code fails it.
• Proof: with the app, its hostd and an atlas mcp running from the install folder, atlas desktop --sync (the exact step that failed) went 21 → 24, and so did desktop --install. Both printed ✓, and the hostd and mcp processes kept running.

3. Installer-only users have no atlas command

The NSIS installer carries atlas.exe but never put it on PATH. New packaging/windows/installer-hooks.nsh (NSIS_HOOK_POSTINSTALL) runs "$INSTDIR\atlas.exe" install (~/.atlas/bin, user PATH, bundled skills) only when ~/.atlas/bin\atlas.exe doesn't exist yet. An existing, newer or linked CLI is never overwritten.

Verification

• clippy -D warnings on atlas-cli and atlas-desktop; nextest on both (793 passed).
• The live runs above, on the user's real install.

Installer run (after the review)

A real NSIS installer built the CI way (tauri build --bundles nsis with the atlas.exe resource) was installed through the fixed path: atlas desktop --install --from <setup.exe>. Conditions: the installed app, its hostd and an atlas mcp all running, and no ~/.atlas/bin/atlas.exe.

• Install: went through.
• App: reopened after the installer closed it (new pid).
• hostd and mcp: the same processes kept running.
• Hook: NSIS_HOOK_POSTINSTALL created ~/.atlas/bin/atlas.exe.

The user's own CLI was restored afterwards. The command did not return to the shell, because the reopened app inherits the console's output handles. That is the known hang when a caller waits on a captured pipe (main has it too); a real terminal is unaffected.

Reopen attribution: Tauri's NSIS installer relaunches the app only with /R (.onInstSuccess), and run_installer passes /S /D= only. So the relaunch observed above came from desktop_windows::open in this change.

atlas update itself was not run end to end with the fix. The step it failed at, the atlas desktop --sync it spawns, did run with the fix against the live install (21 → 24). A full atlas update needs a published release that carries this change. The first one after merging is the real end-to-end check.