[unstatusthequo]

Summary

Add Grok Build (OAuth) to Settings, with a device-code sign-in sheet, account controls, and independent OAuth/provider toggles. Users can open the verification link, copy the code, cancel, and retry. A connection is confirmed only after CLIProxyAPI reports saving a recognizable xAI credential file.

Continues #514

This branch directly cherry-picks @rluisr's three commits from #514, retaining their authorship and recording the original commit IDs. It adapts that work to current main and adds the missing device-code lifecycle handling.

The binary conflict was resolved by retaining main's stock CLIProxyAPI 7.2.151. No backend binary changes are included. The current upstream catalog already includes grok-4.6 and grok-build-0.1, so the custom 7.2.130-grok46 binary from #514 is unnecessary.

Behavior and compatibility

• Retains fix: add Grok 4.6 OAuth support #514's xai-oauth preference → upstream xai exclusion mapping. Custom openai-compatibility providers named xai, their stored/inline API keys, and their enabled state remain independent.
• Preserves manual wildcard exclusions and restores individual exclusions when OAuth is re-enabled.
• Captures split stdout/stderr output continuously, reports delayed denial/expiry/network errors, and ignores stale process callbacks after cancellation/retry. Exit code zero and an early success message alone are insufficient.
• Keeps the Services form scrollable and adds setup/model-discovery documentation. Corrects the current CLIProxyAPI attribution.
• Uses the existing HTTP proxy and stock upstream OAuth routing. No new model aliases, request translation, media UI, or WebSocket support.

Validation

Final CI run passed on Apple Silicon (macos-15) and Intel (macos-15-intel) at commit ebca1e8:

• swift build and swift test: 22 tests passed on each architecture.
• All four standalone verification programs passed: ConfigComposer, ConfigInputFingerprint, CustomProviderCredentialStore, and ZAIAPIKeyStore.
• Native app bundles built successfully on both architectures; packaged backend exposes --xai-login and reports 7.2.151.
• Offline synthetic-account checks confirm grok-4.6 and grok-build-0.1 model registration, including the checked-in ARM backend.
• Device-code sheet rendered and visually inspected in light and dark appearances; previews are available as CI artifacts.
• git diff --check origin/main HEAD passed. The tracked backend binary is unchanged.

Live-account checks still require an eligible Grok Build account and an interactive Mac. These have not been performed:

• Browser authorization, Settings scrolling, and account removal/disable controls in a running app.
• Requests through port 8317: Chat Completions and Responses, including streaming and a function-call/result round trip.
• Token refresh with real credentials.

The automated account fixtures contain synthetic tokens only; offline model discovery is not proof of account entitlement or successful inference.

[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	✅ Completed 2026-09-06T00:22:12.430997Z	ebca1e8	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.

[unstatusthequo]

@ranaroussi, any chance you can review this for merging?

[rluisr]

I stopped using vibeproxy and switched to cliproxyapi because there was no response from the maintainer and it seemed like no maintenance was being done. Since cliproxyapi has a proper Web UI as well, there is no longer any reason to use VibeProxy. You can also use xAI OAuth with it.

[ranaroussi]

Reviewed in full, and thank you for the care that went into this. It is the strongest PR in the current queue.

I verified the core premise directly against the bundled backend on main (CLIProxyAPI 7.3.17): it exposes xai-login and registers both grok-4.6 and grok-build-0.1. So the stock binary does the work and no custom backend build is needed, which is exactly the argument you made for superseding #514.

What I checked in the Swift side and liked:

• Separate stdout and stderr byte buffers, since UTF-8 sequences and lines can split across reads and the two streams interleave.
• Success requires both the "Authentication saved to" line and a credential file on disk with type: xai and a non-empty token. Given that upstream prints success before persisting, treating exit code 0 as insufficient is the correct call.
• The verification URL is only accepted when it is https on x.ai or a subdomain, with no embedded user or password.
• Raw subprocess output never reaches the UI, with mapped messages instead. That matters because the output can carry credentials.
• Stale attempts are ignored after cancel or retry, and termination escalates to SIGKILL.
• 22 tests plus a two-architecture CI workflow.

Three things I want to settle before merging:

1. verify.yml. This repository currently runs nothing on pull_request, so adding PR CI is welcome, but I want to review the workflow on its own terms rather than as part of a provider PR. The pending fork workflow approval is also why this PR shows as UNSTABLE with an empty check rollup.
2. Attribution change. You rewrite CLIProxyAPIPlus to CLIProxyAPI in the README and the Settings footer link. You are technically right that release.yml pulls from router-for-me/CLIProxyAPI, but the branding is a call I want to make deliberately and consistently across the app, not as a side effect here.
3. .scrollDisabled(expandedRowCount == 0) removal. Dropping the onExpandChange plumbing so the Services form is always scrollable is probably an improvement, but it is an unrelated UX change bundled into a provider PR. Please confirm it was intentional and that expanded rows still behave in a tall window.

Also note this touches SettingsView.swift and ServerManager.swift substantially, so it will need sequencing against #485. I plan to land the smaller provider PRs first, then this.