[samjulien]

Local evaluation login failed with invalid_redirect_uri because OpenBot opened /auth/signin on the API origin, while the local OIDC client registers its callback on the dashboard origin. Session cookies also belong to the dashboard host.

The setup helper discovers CLI-managed local stacks through the public copilotkit local list --json contract and uses the matching dashboard for sign-in and session requests. It preserves the configured API URL in the runtime connection.

• Discovery runs an installed or npm-cached CopilotKit CLI through the absolute Bun executable. Desktop launched from Finder does not need npx on PATH, and discovery does not download packages or contact a registry.
• Missing CLI installation falls back to the existing API-origin login for manually hosted deployments. Invalid CLI responses, failures, and ambiguous dashboard mappings still stop before opening a browser.
• Matching treats localhost, IPv4 loopback and IPv6 loopback as equivalent while preserving protocol and port.
• Discovery has a bounded timeout, supports cancellation, suppresses CLI diagnostics that could contain sensitive data, and reports an error suitable for Desktop users.

Validation: 61 focused tests passed, including actual child execution with a minimal PATH, installed/cache resolution, malformed metadata, offline behavior, cancellation, timeouts, dashboard routing and loopback aliases. Changed-file formatting/lint, explicit script typechecks, server typecheck/build passed. Server-test types match this branch's existing 241-error baseline with no new errors. Read-only discovery using the real cached CLI under Finder-style PATH returned the local stack inventory in approximately 0.9 seconds. A complete interactive browser sign-in was not repeated; the local auth service still requires its normal approval.

[dustywusty]

Right diagnosis. Moving sign-in and session requests to the dashboard origin is the fix. I checked that copilotkit@latest local list --json returns the shape this parses, and on a live stack learningSessionOrigin("http://localhost:56323") resolves to http://cpk.localhost:56324. Tests pass locally.

One blocker, though: in the packaged Desktop app this can break sign-in for local deployments.

Blocker: Desktop opened from Finder has no npx on PATH

Desktop spawns this helper with bun, and the helper then runs runCli, which spawns npx. On macOS an app opened from Finder or the Dock gets the minimal launchd PATH (/usr/bin:/bin:/usr/sbin:/sbin), so npx isn't found. runCli resolves exitCode: 127, and learningSessionOrigin throws. Desktop already works around this for bun (which_bun in desktop/src-tauri/src/main.rs falls back to ~/.bun/bin/bun), but nothing does the same for npx.

Repro, with bun run by absolute path the way Desktop does it:

$ env PATH=/usr/bin:/bin:/usr/sbin:/sbin bun probe.ts
http://localhost:56323 -> THROWS: Could not identify the local Intelligence dashboard for this API. …
http://localhost:1234  -> THROWS: Could not identify the local Intelligence dashboard for this API. …

(56323 is a CLI-managed stack. 1234 has no CLI record. With a full shell PATH they resolve to http://cpk.localhost:56324 and http://localhost:1234.)

So:

• CLI-managed stacks: the fix doesn't apply in the packaged app.
• Manually hosted local deployments: this is a regression. They work today, but now fail before the browser opens. The matches.length === 0 fallback only covers "the CLI ran and found nothing". It doesn't cover "the CLI couldn't run".

Suggested direction:

1. Separate "the CLI couldn't run" (spawn failure / 127) from "the CLI ran and returned something invalid". Fall back to apiUrl for the first. Throw only for the second.
2. Make CLI-managed stacks work from Desktop. Either give the helper a PATH that can find npx, or have Desktop discover the dashboard itself and pass it in (e.g. --session-origin).

Smaller things

• Latency / offline: every localhost setup now runs npx --yes copilotkit@latest before the browser opens. On a cold cache that's a package download, with up to the 2-minute runCli timeout and no progress event. Offline, it fails outright.
• Exact origin match: http://127.0.0.1:56323 won't match the CLI's http://localhost:56323. Nothing matches, so it quietly falls back to the API-origin sign-in that fails with invalid_redirect_uri. Consider treating loopback hosts as equivalent when comparing.
• Error copy in Desktop: "Run copilotkit local list --json and check the saved dashboard URL for INTELLIGENCE_API_URL" is fine from the script. Desktop users don't have that env var, though, so the message probably needs a Desktop-appropriate variant.

[dustywusty]

Thanks, all addressed. I checked each one with a Finder-style environment (PATH=/usr/bin:/bin:/usr/sbin:/sbin, only HOME set, bun by absolute path):

• CLI-managed stack: discovery found the npx-cached CLI and resolved http://localhost:56323 to http://cpk.localhost:56324 in about 200–560 ms, with no download.
• No CLI anywhere (empty home): it falls back to the API origin, so manually hosted deployments keep working.
• Loopback alias: http://127.0.0.1:56323 resolves to the same dashboard.
• 31 tests across the two test files pass locally.

Two non-blocking notes for later:

• Installed copies win over the npx cache, even when they're older. A stale global copilotkit that predates local list exits non-zero. That's treated as invalid discovery, so setup fails instead of falling back. Rare, but preferring the newest version across both sources, or treating "unknown command" like 127, would avoid it.
• Windows only finds a global install. The npx cache lookup defaults to ~/.npm/_npx, but npm's default cache on Windows is %LOCALAPPDATA%\npm-cache. Without a global install, Windows falls back to the API-origin sign-in. That's harmless while the CLI refuses Windows, but worth fixing when that changes.