[dustywusty]

What

On macOS and Windows, a new OpenBot Desktop installation picks its container engine in this order:

1. Docker answers: it is used as it is.
2. Docker Desktop is installed but stopped, and has run before: it is opened and used. "Run before" means its VM disk exists, so its terms were accepted and its first-run screens are done.
3. Otherwise, Podman: the Podman already installed, or one OpenBot installs, as before. This includes a Docker Desktop that was installed and never opened, and a docker command that does not answer.

The engine chosen is saved with the installation (.openbot-engine.json in the installation folder, read with preparation::saved_engine). Every later install, Start and sign-in uses only that engine:

• A Podman installation never moves to a Docker that happens to answer, and the reverse. Moving would start OpenBot with none of its images and an empty database.
• A saved Docker whose Docker Desktop is stopped is opened before Start. It answered for this installation before. The wait is limited to 3 minutes. If Docker Desktop stops on a screen of its own (updated terms, a required sign-in), the person is told to finish it there.
• An installation from before this record is pinned to the engine its images are found on, at its next successful Start.

Start brings the engine up. Before, only install started the Podman machine. Reopening OpenBot goes straight to Start, which only looked for an engine, so after a restart a Podman installation failed with "podman is installed but not answering. Start it and try again." Now Start first brings up the saved engine:

• A saved Docker opens Docker Desktop.
• A saved Podman, or an installation from before this record with nothing answering, starts OpenBot's own openbot machine when it exists.

No machine is created at Start, and nobody else's is started. An older installation that was on Docker cannot land on an empty machine: Start requires the installation's images on the engine it uses.

Linux: a Docker that answers is used, and anything else gets Podman, as before.

Why

With Docker Desktop installed but quit, setup found no engine that answered and installed Podman behind an administrator prompt, a second engine on a machine that already had Docker.

The first fix opened any installed Docker Desktop and waited 5 minutes for Docker. A Docker Desktop that was never opened shows Docker's subscription terms first. From outside, OpenBot cannot tell that window from a password prompt, a required sign-in or a slow boot, so it would put a person in front of Docker's terms and wait on them. OpenBot must never do that.

How "has run before" is checked

Docker Desktop's VM disk holds every image and container. Docker creates it when its engine first starts, and Docker Desktop does not run until its terms are accepted. These are the places Docker documents in How to back up and restore your Docker Desktop data:

• macOS: ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw
• Windows: %LOCALAPPDATA%\Docker\wsl\disk\docker_data.vhdx (WSL 2). Also checked: the older wsl\data\docker_data.vhdx and wsl\data\ext4.vhdx, %LOCALAPPDATA%\Docker\vm-data\DockerDesktop.vhdx (Docker VMM) and %ProgramData%\DockerDesktop\vm-data\DockerDesktop.vhdx (Hyper-V).

The check is a stat only. On macOS the disk is inside Docker's app container, where reading or listing raises "would like to access data from other apps". A stat raises nothing: on macOS 27.0.1, stats of Docker.raw (with and without following links) produced no tccd request, while the same process's docker calls do log kTCCServiceSystemPolicyAppDataDetailed requests. OpenBot never runs docker for this check.

A disk moved elsewhere in Docker's settings is not found, and that machine gets Podman, which is the safe side.

Kept from earlier revisions

• No Compose is placed after starting Docker Desktop. It ships its own.
• Once Docker answers after the install step, the Podman machine steps are skipped.
• Docker's own CLI is found wherever Docker Desktop is looked for, ~/Applications included.

OpenBot does not install Docker Desktop.

Test

• install::tests::the_engine_is_chosen_by_this_table covers every row:
  • an answering Docker;
  • a stopped Docker Desktop used before (opened) and never used (Podman), with and without Podman beside it;
  • a stopped docker with no Docker Desktop (Podman);
  • an existing Podman;
  • nothing (Podman installed);
  • a saved Docker (answering, opened, disk moved, none to open);
  • a saved Podman (Docker answering, Docker Desktop used before, Podman removed);
  • Linux.
• Further install::tests run the install step itself for these cases. No Podman is ever installed beside a Docker Desktop that is opened, and a Podman installation never moves to an answering Docker.
• docker_desktop::tests cover:
  • the VM-disk signal (absent, a folder where the disk should be, present) and the documented macOS path;
  • starting a stopped Docker Desktop, and the time limit.
• tests::start_brings_up_the_engine_this_installation_runs_on and a_machine_that_fails_to_start_stops_start_with_its_own_words (main.rs): Start opens Docker Desktop for a saved Docker, starts OpenBot's machine for a saved or older Podman installation, creates or starts no other machine, and does nothing on Linux or when the engine answers.
• preparation::tests::the_saved_engine_outlives_a_new_preparation: the saved engine survives a new release being prepared.
• macOS: cargo fmt --check, cargo clippy --all-targets -- -D warnings and cargo test --lib --bins (659 + 156) pass.
• Windows: cargo xwin check --target x86_64-pc-windows-msvc --all-targets compiles. Windows clippy with -D warnings fails only on dead code and unused imports already on main (vault.rs, provider_oauth_lock.rs, stack.rs), none in this change.

[dustywusty]

Linux and Windows CI failed to compile this branch: root cause and fix

• Error: error[E0282]: type annotations needed for Result<_, std::io::Error> at desktop/src-tauri/src/docker_desktop.rs:232, in jobs core, app (linux) and app (windows).
• Where it entered: the original commit on this branch. The non-macOS launch path was command(&app).spawn().map(|_| Default::default()). Nothing pins the type of Default::default(), so inference fails.
• Why it went undetected: that branch is #[cfg(not(target_os = "macos"))], and the branch was built and tested only on macOS, so the code was never compiled before CI ran it. A Windows cross-check from macOS isn't possible here because ring needs the Windows SDK.
• Fix: .map(|_| std::process::ExitStatus::default()). The default status reads as success, which is right: starting Docker Desktop's executable is the whole job there.
• Evidence: a standalone program with the old expression reproduces the same E0282; the fixed one compiles and runs. CI on this push is the proof for Linux and Windows.

[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-27T22:18:06.079975Z	36f6969	Draft marked ready

ℹ️ 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.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 36f69695af

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[dustywusty]

No Compose download after starting Docker Desktop (048bf48)

• Problem: after setup started a stopped Docker Desktop, it ran place_compose. That function checks Compose through acquire::address(), which is Podman on the openbot machine. On a Mac or PC with Docker only, there is no Podman, so the check failed and setup downloaded a docker-compose provider into OpenBot's tools folder.
• Why nothing used it: Docker's docker compose looks for plugins in its cli-plugins folders, not on PATH. Docker Desktop ships its own Compose plugin.
• Where it entered: 3479d27, the first commit on this branch, which added the Docker Desktop start path and reused the Compose step that was written for Podman.
• Why it went undetected: the download succeeds and is only wasted, so setup does not fail. The unit test used a stub for place_compose that always succeeded.
• Fix: the Docker Desktop branch places no Compose. engine_ready now checks Docker's own Compose after Docker answers (from 8ce0725). If Compose is missing, it shows missing_compose instead of downloading a copy. The test now panics if place_compose is called on this path.
• Not changed: the "Docker already answers" branch still runs place_compose. There, docker can be Podman's compatibility wrapper, which does use a docker-compose on PATH.