@@ -54,7 +54,7 @@ jobs:
         run: cargo package --locked
 
   windows-check:
-    name: Windows compile check
+    name: Windows build and test
     runs-on: windows-latest
 
     steps:
@@ -70,5 +70,10 @@ jobs:
         # Swatinem/rust-cache v2
         uses: Swatinem/rust-cache@42dc69e1aa15d09112580998cf2ef0119e2e91ae
 
-      - name: Check Windows build
-        run: cargo check --all-targets --all-features --locked
+      # Building the test binaries exercises every cfg(windows) code path
+      # (including cfg(test) modules), and running them covers registry
+      # command construction, wrapper argument forwarding/error propagation,
+      # and setup-launcher argument construction with pure, seam-based unit
+      # tests that never touch the real registry or spawn a real terminal.
+      - name: Run Windows tests
+        run: cargo test --all-targets --all-features --locked
@@ -51,6 +51,7 @@ libc = "0.2"
 pulldown-cmark = "0.10"
 clap = { version = "4", features = ["derive"] }
 notify = "6"
+url = "2.5"
 
 [build-dependencies]
 winresource = "0.1.31"
 
@@ -16,8 +16,16 @@
 //!      `CREATE_NO_WINDOW` so the child never gets a console allocated.
 //!   3. If launched directly with no file args, opens onboarding: Windows
 //!      starts the terminal setup in Windows Terminal when available; Linux
-//!      opens `mdo-setup` for native first-run onboarding.
-//!   4. Exits immediately. The child runs detached and pops the browser.
+//!      opens `mdo-setup` for native first-run onboarding. This step is
+//!      fire-and-forget (there is nothing meaningful to wait on: the
+//!      interactive setup runs in a separately-launched window).
+//!   4. For the `--open` case, waits for the `mdo`/`mdo-open` child to exit
+//!      and mirrors its exit code. `CREATE_NO_WINDOW` (Windows) means the
+//!      child never gets a console regardless of whether we wait on it, so
+//!      waiting does not reintroduce the flash; it just lets a real render
+//!      or browser-launch failure surface as a non-zero exit from
+//!      `mdo-open` instead of always reporting success. The wait is brief —
+//!      the child only has to render and hand off to the browser launcher.
 //!
 //! Net result: registering `mdo-open.exe "%1"` in the Explorer file
 //! association gives a flash-free double-click experience without changing
@@ -62,14 +70,26 @@ fn main() -> ExitCode {
 
     #[cfg(target_os = "windows")]
     {
-        let result = if args.is_empty() {
-            spawn_windows_onboarding(&exe_path)
-        } else {
-            spawn_windows_open(&exe_path, args)
-        };
+        // Onboarding has no exit status worth propagating: it fires off a
+        // detached `wt` (or a new console as a fallback) and returns as soon
+        // as that spawn succeeds, well before the interactive setup inside
+        // it runs. There is nothing to wait on there.
+        if args.is_empty() {
+            return match spawn_windows_onboarding(&exe_path) {
+                Ok(()) => ExitCode::SUCCESS,
+                Err(_) => ExitCode::from(1),
+            };
+        }
 
-        match result {
-            Ok(()) => ExitCode::SUCCESS,
+        // The `mdo --open` child is CREATE_NO_WINDOW either way, so waiting
+        // on it does not reintroduce the console flash this binary exists to
+        // avoid — no console is ever allocated for it, waited-on or not. It
+        // also exits quickly (render + browser launch), so this keeps
+        // `mdo-open.exe` responsive while letting a real failure (bad
+        // Markdown path, no browser handler, ...) surface as a non-zero exit
+        // instead of always reporting success.
+        match spawn_windows_open(&exe_path, args) {
+            Ok(status) => exit_code_from_status(status),
             Err(_) => ExitCode::from(1),
         }
     }
@@ -98,15 +118,39 @@ fn main() -> ExitCode {
             cmd
         };
 
-        match cmd.spawn() {
-            Ok(_) => ExitCode::SUCCESS,
+        // Non-Windows binaries never had a console-flash problem to begin
+        // with (that's Windows Explorer + console-subsystem-exe behavior),
+        // so there's no reason to stay fire-and-forget here: wait for the
+        // child (either `mdo --open`, which exits quickly, or `mdo-setup`,
+        // which itself only blocks when it decides to run onboarding inline
+        // in an already-attached terminal) and propagate its exit status.
+        match cmd.status() {
+            Ok(status) => exit_code_from_status(status),
             Err(_) => ExitCode::from(1),
         }
     }
 }
 
+/// Map a child's exit status onto an `ExitCode`. Signals/unknown termination
+/// (no exit code available) fall back to a generic failure code rather than
+/// panicking or silently reporting success. Windows exit codes are 32-bit, so
+/// a failure whose low byte is zero (e.g. 0x100) must not truncate to
+/// "success"; any failing status maps to a non-zero code.
+fn exit_code_from_status(status: std::process::ExitStatus) -> ExitCode {
+    if status.success() {
+        return ExitCode::SUCCESS;
+    }
+    match status.code() {
+        Some(code) if code as u8 != 0 => ExitCode::from(code as u8),
+        _ => ExitCode::FAILURE,
+    }
+}
+
 #[cfg(target_os = "windows")]
-fn spawn_windows_open(exe_dir: &Path, args: Vec<std::ffi::OsString>) -> io::Result<()> {
+fn spawn_windows_open(
+    exe_dir: &Path,
+    args: Vec<std::ffi::OsString>,
+) -> io::Result<std::process::ExitStatus> {
     let mut cmd = Command::new(exe_dir.join(MDO_BIN));
     cmd.arg("--open");
     cmd.args(args);
@@ -130,14 +174,18 @@ fn spawn_windows_onboarding(exe_dir: &Path) -> io::Result<()> {
 }
 
 #[cfg(target_os = "windows")]
-fn spawn_without_console(mut cmd: Command) -> io::Result<()> {
+fn spawn_without_console(mut cmd: Command) -> io::Result<std::process::ExitStatus> {
     use std::os::windows::process::CommandExt;
 
     // CREATE_NO_WINDOW (0x0800_0000) tells Windows not to give the child a
     // console of its own. Without it, even though *we* have no console, the
     // child (a console-subsystem exe) would briefly get one allocated —
-    // exactly the flash we are trying to avoid.
+    // exactly the flash we are trying to avoid. This holds whether we wait
+    // on the child afterwards (as we now do, to propagate its exit status)
+    // or not: the flag controls console allocation at spawn time, not
+    // whether the parent waits.
     const CREATE_NO_WINDOW: u32 = 0x0800_0000;
     cmd.creation_flags(CREATE_NO_WINDOW);
-    cmd.spawn().map(|_| ())
+    let mut child = cmd.spawn()?;
+    child.wait()
 }