Desktop 0.0.27: browser OAuth sign-in fails while sidecar is not ready (Intel macOS, Brave/Choosy)

Cline Surface

Desktop App

Cline Version

0.0.27 (beta)

Beta version

• I am using a beta version of Cline

What happened?

Cline Desktop's Sign in with Cline (browser OAuth) did not complete on a fresh 0.0.27 install. I had to fall back to a Cline API key.

Expected: click Sign in → browser opens (WorkOS / app.cline.bot) → confirm in the app → account connected.

Actual: the desktop sidecar is not ready when the webview tries to talk to it, so the OAuth round-trip never gets a working transport. Logs from the same launch:

1. Sidecar: Login shell PATH resolution failed (shell: /bin/zsh).
2. First sidecar process: fatal No compatible hub runtime is available.
3. After respawn: sidecar eventually reports Desktop sidecar ready on port 3126.
4. Webview still errors: Tauri invoke failed for get_desktop_backend_endpoint: desktop backend endpoint not ready (operation: webview.transport_connect, transportState: connecting).

That matches get_desktop_backend_endpoint in apps/examples/desktop-app/src-tauri/src/main.rs: it polls ~15s for the sidecar WS endpoint, then returns "desktop backend endpoint not ready". Comments there note sidecar startup includes login-shell PATH resolution bounded at 3s.

OAuth login is sidecar-backed (Waiting for browser...). If the webview cannot resolve the backend endpoint, Sign in cannot start or appears stuck, which is why the API-key path was the only way in.

Environment notes that likely make this worse than a Chrome-default Mac:

• No Google Chrome. Only Brave.
• Default http/https handler is Choosy, which then opens Brave.
• Cline.app Info.plist has no CFBundleURLTypes, so there is no cline:// (or similar) callback; the flow depends on the sidecar being up plus a localhost/WorkOS device round-trip in the system browser.

Related: #12564 already added the API-key escape hatch because the browser round-trip can fail; #13842 (Sign Up stuck after cancel). This report is the launch race / sidecar not ready that forces that escape hatch on Intel macOS with a non-Chrome default browser.

Steps to reproduce

1. Intel Mac, macOS 13.6 (Ventura / darwin 22.6.0). Default browser Brave via Choosy. Google Chrome not installed. Node is via nvm (PATH set in ~/.zprofile / ~/.zshrc).
2. Install Cline Desktop 0.0.27 from https://cline.bot/desktop and launch it.
3. On first launch, immediately try Sign in with Cline (browser).
4. Observe Sign in not completing; ~/.cline/data/logs/code.log shows PATH failure, hub-runtime failure, then desktop backend endpoint not ready.
5. Completing setup only via Use a Cline API key instead.

Provider/Model

cline (account sign-in; never reached a model via OAuth)

Diagnostics

• App: Cline Desktop 0.0.27, bundle id bot.cline.app, binary cline-app.
• Sidecar binary: code-sidecar-x86_64-apple-darwin (Intel).
• Hub (after retry): ws://127.0.0.1:25463/hub, core 0.0.82.
• Sidecar transport port after ready: 3126.
• Log file: ~/.cline/data/logs/code.log (2026-09-14T22:51Z).

Sanitized log excerpts:

Login shell PATH resolution  status=failed  shell=/bin/zsh
Desktop sidecar process failed  Error: No compatible hub runtime is available.
Using hub runtime host  url=ws://127.0.0.1:25463/hub
Desktop sidecar ready  port=3126
webview.transport_connect  Tauri invoke failed for get_desktop_backend_endpoint: desktop backend endpoint not ready

System Information

• OS: macOS 13.6 (darwin 22.6.0)
• Arch: x86_64 (Intel MacBook Pro)
• Default URL handler: Choosy (com.choosyosx.choosy) → Brave Browser
• Chrome: not installed
• Node: nvm (~/.nvm/versions/node/v22.23.2/bin/node) — not on a GUI-app default PATH unless login-shell resolution succeeds

Suggested fix (from the logs / code)

• Do not enable Sign in until get_desktop_backend_endpoint succeeds; retry that invoke after sidecar ready instead of failing the webview connect once.
• Raise or retry the 3s login-shell PATH probe (nvm users commonly miss the first window).
• On macOS, register a URL scheme or always use WorkOS device-code with the code shown in-app (already mentioned in desktop release notes) even if the first open goes through Choosy/Brave.
• If hub runtime is incompatible on first spawn, fail visibly in the UI instead of leaving Sign in dead.

Happy to add more logs or a screen recording.