feat(grok): add Grok CLI provider via ACP

[Jaaneek]

What Changed

#2808
Add Grok Build via ACL

Why

Grok Build was recently released and its accessible via X Premium Subs and Supergrok Subs

UI Changes

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

Medium Risk
Large new provider surface (child processes, ACP, xAI extensions) plus new orchestration rules for model switching; well covered by tests but touches turn-start paths.

Overview
Adds Grok as a first-party provider: GrokDriver runs the Grok CLI over ACP (grok agent stdio), with health checks, ACP model discovery, a full GrokAdapter (sessions, turns, permissions, xAI ask_user_question), and headless GrokTextGeneration for git/thread helpers.

Grok is flagged with requiresNewThreadForModelChange. The server ProviderCommandReactor rejects mid-thread model switches when that flag is set; the web composer mirrors this with a warning toast via getStartedThreadModelChangeBlockReason.

Contracts/settings gain GrokSettings, default model grok-build, and optional requiresNewThreadForModelChange on provider snapshots. UI adds Grok to the picker (icon, settings, “new” badge). Tests and the ACP mock agent are extended for Grok models, custom approval option IDs, and xAI extensions.

^{Reviewed by Cursor Bugbot for commit 2fb6598. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add Grok as a CLI provider via ACP with full text generation and session management

• Introduces a complete Grok provider driver including ACP-based session management, model discovery, periodic status refresh, and text generation (commit messages, PR content, branch names, thread titles) via makeGrokTextGeneration.
• Adds GrokAdapter and GrokProvider modules wiring the Grok CLI (grok agent stdio) into the existing provider infrastructure, with auth method selection based on XAI_API_KEY presence.
• Supports xAI-specific ACP extensions including ask_user_question request/response handling and session/set_model for per-session model switching.
• Blocks mid-thread model changes for providers advertising requiresNewThreadForModelChange at both the server (ProviderCommandReactor) and UI (ChatView) layers, surfacing a toast warning or a ProviderAdapterRequestError.
• Registers Grok in settings schemas, the built-in driver list, the session model picker, and the settings UI with an 'Early Access' badge.
• Behavioral Change: threads using Grok (or any provider with requiresNewThreadForModelChange) will reject thread.turn.start when the model changes mid-session; users must start a new chat to switch models.

^{Macroscope summarized 1aa7fc2.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 5138595e-6fe4-4632-8ce4-f4831045c6a1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces a complete new provider integration (Grok via ACP) with ~3700 lines of new code across multiple new files including adapters, drivers, text generation, and UI changes. New features of this scope introducing new user-facing capabilities and provider integrations require human review. Additionally, there are unresolved high-severity review comments.

^{You can customize Macroscope's approvability policy. Learn more.}

[anxkhn]

was looking for this, would really appreciate if it's tested well and merged to main soon.

[gmackie]

Thanks for pushing this forward. I think the concurrency comments are valid and not really Grok-specific; they belong at the shared ACP adapter boundary.

A safe shape is:

1. prevent overlapping sendTurn calls for the same ACP session/thread, without holding the same lock across session/prompt in a way that would deadlock approval/cancel flows;
2. ensure every emitted turn.started gets a terminal event even when session/prompt fails;
3. coordinate interruptTurn with the same per-thread session state used by send/stop.

I opened #2932 with that shape for review. It extracts Cursor/Grok into a shared makeAcpProviderAdapter(...), adds Grok Build as a thin wrapper using grok --agent build agent stdio, and includes regressions for prompt failure after turn.started plus overlapping turns. The intent is that these lifecycle concerns are fixed once for ACP providers rather than copied into each provider adapter.

[cursor]

Stale env baked in launcher

High Severity

On macOS dev, the launcher shell script embeds export lines for VITE_DEV_SERVER_URL, T3CODE_PORT, and the derived T3CODE_DESKTOP_PROTOCOL_CALLBACK_URL when the bundle is built. Launcher reuse skips rewriting that script, so those exports override fresher values from dev-electron.mjs and can point Electron and cloud auth callbacks at the wrong host or port.

Additional Locations (1)

• apps/desktop/scripts/electron-launcher.mjs#L277-L295

 

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

[macroscopeapp]

🟠 High cloud/relayClientInstallDialog.ts:48

In requestRelayClientInstallConfirmation, publish() is called before resolveConfirmation is assigned. Since publish() synchronously invokes all listeners, if any listener calls respondToRelayClientInstallConfirmation() synchronously, that function checks resolveConfirmation (still null or stale) and returns early without resolving. The returned Promise then hangs forever. Consider assigning resolveConfirmation before calling publish().

-export function requestRelayClientInstallConfirmation(version: string): Promise<boolean> {
-  if (state.status !== "idle") {
-    return Promise.reject(new Error("A relay client installation is already in progress."));
-  }
-
-  publish({ status: "confirming", version });
-  return new Promise<boolean>((resolve) => {
-    resolveConfirmation = resolve;
-  });
-}

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/cloud/relayClientInstallDialog.ts around lines 48-57:

In `requestRelayClientInstallConfirmation`, `publish()` is called before `resolveConfirmation` is assigned. Since `publish()` synchronously invokes all listeners, if any listener calls `respondToRelayClientInstallConfirmation()` synchronously, that function checks `resolveConfirmation` (still `null` or stale) and returns early without resolving. The returned Promise then hangs forever. Consider assigning `resolveConfirmation` before calling `publish()`.

Evidence trail:
apps/web/src/cloud/relayClientInstallDialog.ts lines 48-57 (requestRelayClientInstallConfirmation): publish() on line 53 before resolveConfirmation assignment on line 55. Lines 30-35 (publish): synchronously invokes all listeners. Lines 59-62 (respondToRelayClientInstallConfirmation): returns early if !resolveConfirmation.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

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