fix(setup): launch the docker app the CLI is actually pointed at by waleedlatif1 · Pull Request #6253 · simstudioai/sim

waleedlatif1 · 2026-08-04T17:42:38Z

Summary

Carries over #6250 by @BohdanVilischuk (commits cherry-picked, authorship preserved) and adds a follow-up fix. Full credit for finding and fixing this goes to them.

bun run setup only knew how to relaunch Docker Desktop, so OrbStack users got open -a Docker against an app they don't have, a 90s wait, then an error about Docker Desktop's license screen. The wizard now detects which app owns the docker CLI and launches, prompts, and errors with the right name.
Follow-up: detection only fell back to the installed app bundle when docker context show failed outright. An OrbStack-only Mac sitting on the default context (OrbStack symlinks /var/run/docker.sock; also anyone who ran docker context use default) still resolved to Docker Desktop — the same hang the fix exists to remove. An explicit OrbStack selection is now the only positive context signal; otherwise we pick whichever app is actually installed, which also covers CLIs too old for docker context show.
Follow-up: read DOCKER_HOST first. It overrides the active context, so the context name isn't authoritative while it's set.

Docker Desktop stays the tiebreak when both apps are installed and nothing points at OrbStack, matching today's behavior. Non-macOS paths are untouched.

Type of Change

Bug fix

Testing

Verified the resolver against a real Docker Desktop install (context desktop-linux) plus shimmed docker binaries covering every branch:

Signal	Resolves to
no `DOCKER_HOST`, context `desktop-linux`	Docker
`DOCKER_HOST=unix://…/.orbstack/run/docker.sock`	OrbStack
`DOCKER_HOST=tcp://…` (remote daemon)	Docker
`DOCKER_CONTEXT=orbstack`	OrbStack
context `orbstack`	OrbStack
context `default`, Docker.app installed	Docker
`docker context show` exits non-zero (old CLI)	falls back to installed app

Checklist

Code follows project style guidelines
Self-reviewed my changes
Tests added/updated and passing
No new warnings introduced
I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

vercel · 2026-08-04T17:42:44Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview	Aug 4, 2026 6:20pm

cursor · 2026-08-04T17:42:49Z

PR Summary

Low Risk
Changes are confined to the setup wizard’s macOS Docker auto-start path; no runtime services, auth, or data handling are affected.

Overview
Fixes bun run setup on macOS when the Docker daemon is down: the wizard no longer always runs open -a Docker and blames Docker Desktop’s license screen. It infers which provider the docker CLI is using—DOCKER_HOST (OrbStack socket paths), active context orbstack, or which of OrbStack.app / Docker.app is installed—and uses that name in confirm prompts, spinner text, and failure hints.

Launch logic tries the chosen app first; if the choice was only a guess (not an explicit OrbStack selection), it can retry the other GUI app. Explicit OrbStack targeting does not fall back to Docker Desktop, since docker info would still hit OrbStack’s socket. When neither app can be opened, hints mention colima and install options instead of only Docker Desktop.

Optional required=false paths (e.g. Postgres container choice) warn via launchFailed instead of always throwing; required=true compose mode still fails with SetupError. Linux and non-macOS behavior is unchanged.

^{Reviewed by Cursor Bugbot for commit a127fe7. Configure here.}

greptile-apps · 2026-08-04T17:45:12Z

Greptile Summary

The PR adds macOS Docker-provider detection and provider-specific launch, prompt, timeout, and recovery messages.

Detects OrbStack from DOCKER_HOST or the active Docker context.
Uses installed application bundles to choose a provider when no explicit OrbStack signal exists.
Falls back to the alternate provider when a guessed application cannot be opened.
Preserves non-fatal behavior for setup modes where Docker is optional.

Confidence Score: 4/5

The PR is not yet safe to merge because stale OrbStack configuration can still block required setup even when Docker Desktop is installed.

The reply from "" claims the stale-selection issue was fixed, but current code still marks every OrbStack signal explicit without checking installation and refuses to try Docker Desktop when opening OrbStack fails.

Files Needing Attention: scripts/setup/docker.ts

Important Files Changed

Filename	Overview
scripts/setup/docker.ts	Adds provider-aware Docker startup, but an explicit stale OrbStack signal still suppresses fallback to an installed Docker Desktop application.

_{Reviews (6): Last reviewed commit: "improvement(setup): don't tell CLI-runti..." | Re-trigger Greptile}

waleedlatif1 · 2026-08-04T17:47:10Z

@greptile

waleedlatif1 · 2026-08-04T17:47:11Z

@cursor review

waleedlatif1 · 2026-08-04T17:53:17Z

@greptile

waleedlatif1 · 2026-08-04T17:53:18Z

@cursor review

…daemon ensureDocker() always ran `open -a Docker` to relaunch a stopped daemon on macOS, which silently no-ops for OrbStack users (no Docker.app bundle exists), leading to a misleading "GUI license acceptance" timeout error. Now it checks the docker CLI's active context first (accurate regardless of install location) and falls back to checking for OrbStack.app, so the wizard launches and messages the app that's actually installed.

…er Desktop context macDockerApp() fell through to the OrbStack.app existence check whenever docker context show returned anything other than "orbstack" — including a known, explicit context like "desktop-linux". With both apps installed but Docker Desktop active and stopped, this launched OrbStack while daemonUp() kept polling Docker Desktop's socket, timing out with OrbStack-flavored guidance for a Docker Desktop problem. The path fallback now only runs when the context command gives no answer at all (null); any resolved context is trusted outright. Flagged identically by Greptile and Cursor Bugbot on PR #6250.

…Stack Context detection only fell back to the app bundle when `docker context show` failed outright, so an OrbStack-only Mac sitting on the `default` context still resolved to Docker Desktop — the same 90s hang this fix exists to remove. Treat an explicit OrbStack selection as the only positive context signal and otherwise pick whichever app is installed. Read `DOCKER_HOST` first: it overrides the active context, so the context name is not authoritative while it is set.

A context or DOCKER_HOST left behind by an OrbStack uninstall selected an app that can never launch, turning a working Docker Desktop start into a guaranteed 90s timeout. Gate the OrbStack signal on the bundle being present and fall through to whichever app is. Look in ~/Applications as well as /Applications while here — Homebrew casks honour --appdir, so a user-local install is not unusual and a hardcoded /Applications check would misread it as "not installed".

…paths A Homebrew `--appdir` can put OrbStack anywhere, so enumerating install directories will always have a tail that reads a present app as missing and sends setup to the wrong one. Fall back to LaunchServices when the well-known directories miss: that is the same lookup `open -a` performs, so availability now agrees with what the launch will actually do.

`path to application` can raise a modal "Where is …?" picker when the name does not resolve, which in a terminal wizard reads as a hang. Drop it: the launch itself already answers the question, since `open` exits non-zero when macOS knows no such app, instantly and without UI. That inverts the design. Rather than predict which app is installed and then launch it, pick a provider, try to start it, and let the exit code correct a guess — so the directory probe no longer has to enumerate every possible install location to be right. An explicit OrbStack selection is now never redirected to Docker Desktop. The CLI is addressing OrbStack's socket, so `docker info` keeps failing no matter how well Docker Desktop starts; the earlier fallback only replaced a 90s timeout with a differently worded one. Say the context is stale and how to fix it instead.

waleedlatif1 · 2026-08-04T18:04:21Z

@greptile

waleedlatif1 · 2026-08-04T18:04:22Z

@cursor review

db.ts and redis.ts call ensureDocker(false) and branch on the boolean to offer an external Postgres or Redis instead. Throwing past that aborts the whole wizard when a working non-Docker path was on the table, so every post-confirm failure now warns and returns false unless Docker is required. That covers the 90s-timeout throw too, which ignored `required` before this branch existed — leaving it as the one path that still aborts would make the flag mean two different things in one function. Also name DOCKER_CONTEXT in the stale-selection hint. It overrides the config context, so `docker context use` alone leaves the CLI pointed at OrbStack and the next run fails identically.

waleedlatif1 · 2026-08-04T18:13:18Z

@greptile

waleedlatif1 · 2026-08-04T18:13:19Z

@cursor review

cursor

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit b07b731. Configure here.}

…sktop Having the docker CLI but neither GUI app is exactly what a colima or Rancher Desktop user looks like, and the failure told them to install Docker Desktop — advice for a problem they don't have. Name the situation accurately and add starting an existing runtime as an option.

waleedlatif1 · 2026-08-04T18:18:26Z

@greptile Re the 4/5 on b07b73172 — "custom-location OrbStack is misclassified when Docker Desktop is also installed". I think this one is a false positive, and I want to lay out the reasoning rather than just re-trigger.

Reaching the guess path at all requires orbstackSelected() to be false, which means no DOCKER_HOST pointing at an OrbStack socket and docker context show is not orbstack. So by construction the docker CLI is not addressing OrbStack. That leaves two reachable contexts:

desktop-linux — Docker Desktop's own socket. Launching Docker Desktop is simply correct.
default — unix:///var/run/docker.sock, which Docker Desktop serves. Verified on a machine with Docker Desktop running:

$ ls -l /var/run/docker.sock
… /var/run/docker.sock -> /Users/…/.docker/run/docker.sock
$ DOCKER_CONTEXT=default docker info >/dev/null; echo $?
0

So in both cases starting Docker Desktop makes docker info succeed, which is exactly what ensureDocker promises its callers — the daemon the CLI is talking to is up. Where OrbStack is genuinely the target, DOCKER_HOST or the orbstack context says so, that is the explicit path, and it is never redirected.

The --appdir retry from the earlier round covers the case where the guess fails to launch. When the guess succeeds, there is nothing left to retire: the CLI's socket is served and setup proceeds. Sending an unrelated app on top of a working daemon would be the actual bug.

Where I do agree there is residual imprecision: if a user has both apps and prefers OrbStack while sitting on the default context, we start Docker Desktop. That satisfies docker info and unblocks setup, so it is not a failure — and the only signal that could distinguish it is the one they have not set. Guessing against the CLI's own configuration would be worse.

No code change for this one. Latest commit is a127fe706, which adds a hint for colima / Rancher Desktop users who have the CLI but neither GUI app.

waleedlatif1 · 2026-08-04T18:18:27Z

@greptile

waleedlatif1 · 2026-08-04T18:18:28Z

@cursor review

greptile-apps · 2026-08-04T18:19:08Z

The reasoning holds. The invariant is airtight: reaching the guess path proves the CLI is not addressing OrbStack, so starting Docker Desktop is the right call.

The remaining "imprecision" you call out — dual-install user on default who privately prefers OrbStack — still produces a working daemon that satisfies docker info, which is the contract ensureDocker makes. There's no signal available to distinguish it, and guessing against the user's own context configuration would be worse. Acknowledged, and not a bug.

The NO_APP_HINTS addition for colima/Rancher Desktop is a nice touch too — avoids giving wrong advice to users who already have a runtime.

No objection to the current state. The 4/5 comment was a false positive.

cursor

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit a127fe7. Configure here.}

waleedlatif1 mentioned this pull request Aug 4, 2026

fix(setup): detect OrbStack vs Docker Desktop before relaunching the daemon #6250

Closed

10 tasks

greptile-apps Bot reviewed Aug 4, 2026

View reviewed changes

Comment thread scripts/setup/docker.ts Outdated

greptile-apps Bot reviewed Aug 4, 2026

View reviewed changes

Comment thread scripts/setup/docker.ts

vercel Bot deployed to Preview August 4, 2026 17:51 View deployment

cursor Bot reviewed Aug 4, 2026

View reviewed changes

Comment thread scripts/setup/docker.ts Outdated

vercel Bot deployed to Preview August 4, 2026 17:58 View deployment

BohdanVilischuk and others added 6 commits August 4, 2026 11:04

waleedlatif1 force-pushed the worktree-orbstack-docker-launch branch from d6dcd4e to ce25e1d Compare August 4, 2026 18:04

vercel Bot deployed to Preview August 4, 2026 18:08 View deployment

cursor Bot reviewed Aug 4, 2026

View reviewed changes

Comment thread scripts/setup/docker.ts Outdated

Comment thread scripts/setup/docker.ts Outdated

cursor Bot reviewed Aug 4, 2026

View reviewed changes

vercel Bot deployed to Preview August 4, 2026 18:20 View deployment

waleedlatif1 merged commit 47f5fee into staging Aug 4, 2026
24 checks passed

waleedlatif1 deleted the worktree-orbstack-docker-launch branch August 4, 2026 18:21

Uh oh!

Conversation

waleedlatif1 commented Aug 4, 2026

Summary

Type of Change

Testing

Checklist

Uh oh!

vercel Bot commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cursor Bot commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

Uh oh!

greptile-apps Bot commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 4/5

Important Files Changed

Uh oh!

Uh oh!

waleedlatif1 commented Aug 4, 2026

Uh oh!

waleedlatif1 commented Aug 4, 2026

Uh oh!

Uh oh!

waleedlatif1 commented Aug 4, 2026

Uh oh!

waleedlatif1 commented Aug 4, 2026

Uh oh!

Uh oh!

waleedlatif1 commented Aug 4, 2026

Uh oh!

waleedlatif1 commented Aug 4, 2026

Uh oh!

Uh oh!

Uh oh!

waleedlatif1 commented Aug 4, 2026

Uh oh!

waleedlatif1 commented Aug 4, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

waleedlatif1 commented Aug 4, 2026

Uh oh!

waleedlatif1 commented Aug 4, 2026

Uh oh!

waleedlatif1 commented Aug 4, 2026

Uh oh!

greptile-apps Bot commented Aug 4, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

vercel Bot commented Aug 4, 2026 •

edited

Loading

cursor Bot commented Aug 4, 2026 •

edited

Loading

greptile-apps Bot commented Aug 4, 2026 •

edited

Loading