[dustywusty]

What this changes

Opened from Finder or the Dock, the desktop app stops at Start with "OpenBot did not start". The technical details say:

app stopped straight away (exit status: 127). Last from app.log:
$ bun scripts/serve-or-build.ts && bun serve.ts
/bin/bash: bun: command not found
error: script "serve" exited with code 127

Every process the desktop starts now gets the directory of the Bun it installed first on its PATH (stack::bun_command, used by spawn_host_process). The rest of PATH is kept after it.

Root cause

• How: the desktop starts the server, worker and browser by running its own Bun on a file (openbot-engine/bun-1.4.3/bun src/index.ts). It starts the app differently: bun run serve, a package script. That script is bun scripts/serve-or-build.ts && bun serve.ts, which runs bun again by name through the shell. The child inherits the desktop's PATH. An app opened from Finder has macOS's minimal /usr/bin:/bin:/usr/sbin:/sbin, which has no bun. So only the app died, with 127.
• Where it entered:
  • Desktop shell: the window, the engine it acquires, and the stack it raises #392 (c27c1d0c) ran the app as a package script. Its script has called bun by name ever since: bun run build && bun serve.ts, and from perf: speed up web startup and reduce route and preview work #584 (a331c72c) bun scripts/serve-or-build.ts && bun serve.ts.
  • That was harmless while the desktop used the developer's own bun. Fix fresh desktop installation without developer tools #604 (d779eaf6) made the desktop download its own Bun and run it by its full path, for machines without developer tools. Nothing put that Bun on its children's PATH.
• Evidence: reproduced with a desktop build opened with open, on a Mac whose bun is a mise shim (not on the system PATH). The app log is quoted above. The server and worker started; only the app failed.
• Why it went undetected:
  • Desktop runs during development are tauri dev from a terminal, and that PATH has the developer's bun.
  • The host-process tests compile a fixture bun and pass a test PATH. None starts the real serve script with the minimal PATH an app gets from Finder.
• How this prevents recurrence: a_host_process_finds_the_installations_own_bun_by_name checks that a host process's PATH starts with the installation's Bun directory and keeps the rest. With the PATH line removed, it fails (a host process is given a PATH).

Not affected: #832's branch, where #852 replaced the host processes with containers.

Where it runs

• New state that outlives a request? None. Desktop only; the environment of a spawned process.
• What happens on the second replica? Not applicable.
• Anything serialised? No.
• 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 app starts OpenBot when it is opened from Finder").

Proof

• The new test fails without the change and passes with it.
• From desktop/src-tauri: cargo fmt --check, cargo clippy --locked --all-targets -- -D warnings and cargo test --locked --lib --bins pass on macOS arm64. Windows and Linux left to CI.
• The same change in a local desktop build, opened from Finder: see the comment below once checked.

[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	🔄 Running since 2026-10-29T08:55:38.249391Z	3058e82	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.

[davidmckayv]

Approving. The root cause write-up is exact, and the fix is the right size.

• bun_command puts the installation's own Bun directory first and keeps the inherited PATH after it, through the existing path_with, so the serve script's second bun resolves to the same Bun that started it, and the Windows separator is already handled there.
• Nothing later in spawn_host_process replaces PATH: it only adds the port settings and PORT, so the new PATH survives to the child.
• The test pins both halves (installation Bun first, rest of PATH kept) and fails with the line removed.
• Merges cleanly with current main, and CI is green.

One nit, not blocking: the new test sits between use super::*; and use crate::test_support::temp_root; in the tests module. Moving it below the second use keeps the imports together.