[dustywusty]

What this changes

While "Install OpenBot" downloads local software, clicking or focusing the window shows the spinning cursor until the download finishes; the window can also stop repainting. restore_window_on now uses try_lock on shell.startup: when installation holds it, the window is shown and focused as it is (it is already on the setup screen) and only the "setup page or app" decision is skipped, to be made next time. With the lock free, behavior is unchanged.

Root cause

• Where it entered: restore_window_on has taken shell.startup.lock() since Setup, end to end: pick a Bot, connect a model, prove it answers #451 (c21ba2b, 11 Sep). prepare_installation has held the same lock across the whole image download since Fix fresh desktop setup and Mac sign-in #591 (2e43afd, 16 Sep). The freeze dates from Fix fresh desktop setup and Mac sign-in #591, when the two met.
• How: restore_window_on runs on the event-loop (main) thread for the macOS reopen event and for the tray/window menu "Open OpenBot" item, so it blocked the UI thread on a lock held for minutes.
• Evidence: a sample of the live process during an install showed the main thread in application_should_handle_reopen → show_whichever_applies → restore_window_on → Mutex::lock → __psynch_mutexwait.
• Why it went undetected: pulls are usually quick on a fast connection, so the window was rarely focused mid-install long enough to notice; no test held the lock while restoring.
• How this prevents recurrence: restore_window_shows_setup_without_waiting_for_startup_held_by_installation holds the lock on another thread and requires the restore to finish within 5 s with the window visible on the setup page, then checks the normal destination once the lock is free. It failed before the change (Timeout).
• Remaining, not changed here: already_running and last_failure are synchronous Tauri commands that also take the lock on the main thread; the window calls them only when the setup page loads, so they block only if that page reloads mid-install. Making them #[tauri::command(async)] would close that too.

Where it runs

• New state that outlives a request? None. Desktop-only.
• What happens on the second replica? Not applicable.
• Anything serialised? The startup lock is unchanged; the restore no longer waits on it.
• Anything fanned out to a browser? No.
• New listener, port, or schedule? No.

Boundary and audit

• Unchanged; no server code touched.

Changelog

• A line in CHANGELOG.md under Unreleased ("The desktop window answers while software is installing").

Proof

• The new test failed before the fix and passes after, with the 13 existing restore tests.
• cargo fmt --check, cargo clippy --locked --all-targets -- -D warnings, cargo test --locked --lib --bins (541 lib, 150 bin) pass on macOS arm64. Windows and Linux left to CI.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-21T18:49:39.002459Z	2ad3e3f	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.