New 'Custom OpenAI-compatible' and 'Custom Anthropic-compatible' providers let
an agent run against any compatible endpoint by base URL + key: the turn posts
Chat Completions (/chat/completions) or Anthropic Messages (/v1/messages) at the
configured base URL. Backfilled into existing orgs by migration 037.
Closes the Anthropic OAuth gap with a native Claude Pro/Max device sign-in
(reusing the OAuth engine) and adds three OpenAI-compatible API-key
providers. Model lists are sourced from the provider registry. A backfill
migration seeds the new providers into existing organizations idempotently.
Implement the official OAuth login flows natively (ported from pi-ai's
reference): GitHub Copilot device-code, GPT account (ChatGPT Codex) and
Google Antigravity authorization-code + PKCE via a loopback callback server.
Obtained credentials are stored as JSON through the existing secret vault.
Onboarding and Settings now run the real sign-in instead of pasting an
access token.
Onboarding only accepted a typed workspace path, which is error-prone and
diverged from the original wizard. Add a pickDirectory IPC backed by Electron's
open-directory dialog and a Choose button beside the path field, so the founder
can select a real folder for agent artifacts.
The PRD calls for company, division, department, project, pod and ad-hoc
spaces, but only company, department, project and direct were accepted. Add
division, pod and ad_hoc to the command contract, the service whitelist and the
new-space dialog. The space_type column is free text, so no migration is
needed.
The provider step was filtered to API_KEY only, which hid GitHub
Copilot, Google Antigravity, and GPT account from the founding-CEO
runtime picker even though they are first-class providers in the
catalog. Show every non-cloud provider, render an "Access token" field
in place of the API-key field for OAuth and account auths, and surface
a button that opens the provider's official sign-in page via the new
openExternalUrl IPC (validated to http(s) only).
OnboardingService.resolveProvider now accepts any non-cloud auth type.
Cloud providers still route through Settings since their multi-field
config does not fit the linear onboarding step.
ZacharyZhang-NY
