[brennanb2025]

	Files	Added	Deleted	Net
Test	3	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​66	$\color{#cf222e}{\Huge{\mathbf{−}}}$​2	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​64
Prod	14	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​110	$\color{#cf222e}{\Huge{\mathbf{−}}}$​17	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​93

ELI5

Antigravity chats need Google's separate Antigravity chat server. An earlier version of this stack downloaded it silently the first time a chat started: about 18 seconds of "Working for Ns" with no progress and no Cancel, and every extra chat opened started another download. Now nothing downloads until the person clicks Install, which shows the size, progress and Cancel in Settings and in the new chat, and Settings can also remove the download again.

All Antigravity chats on one machine share one Google sign-in and one installed server. If a chat keeps running while you sign in to another account, the server can quietly save the old sign-in back over the new one. If it keeps running while the server is removed, it runs files that are being deleted. This PR adds a short pause around those changes: while one runs, new Antigravity chats are refused with a clear message, chats still starting are cancelled, and every server process is proven stopped before the change begins.

What Changed

This revision: the gate missed one way the server starts. When a chat is opened in the agent's own terminal program, Orca first has the server save a copy of the conversation, and that copy started the server with the shared sign-in folder outside the gate, so a sign-in change could run while that server still held the old sign-in. Conversation copies now enter the gate like a chat start, and the gate holds each copy's server until it exits. This was in #29139 before; it moved here so this PR covers every process it claims to on its own.

• Before: nothing coordinated chat starts with a change to an agent's shared sign-in or installed server.
• After: an Agent Client Protocol (ACP) agent's launch spec can carry a launch gate (AcpLaunchGate). It lives in memory only and always releases when the operation ends.
  • Every chat start, and every conversation copy, enters the gate first. While an operation runs, a new start is refused as "account changing" (the existing accountSwitchInProgress reason).
  • When an operation begins, starts under way are aborted, and the gate waits for them to leave. The operation then stops the running chats it names.
  • The gate also holds every server process it let start, a conversation copy's included, until that process exits. A start leaves the gate once its process is up, but the host lists the chat as running only after it finishes attaching, so a stop that only looked at running chats would miss a chat in that window. Before the operation's work runs, the gate closes each process it still holds, and each must prove it exited.
  • If a chat or process can't be proven stopped, the operation fails without running: "Antigravity could not be stopped on this host. Try again."
• The existing refusal message now names whichever agent it is about and covers every setup change the gate fences. It used to say "A Claude account switch is in progress. Try again after it finishes." and now says "{{agent}}'s setup is changing on this host. Try again after it finishes." in all six languages. Claude's existing account switch now reads "Claude's setup is changing on this host. Try again after it finishes."
• Antigravity sets the gate; no other agent does. The operations that use it are the chat sign-in (feat(antigravity): sign Antigravity chats in with the server's own Google sign-in #28650) and removing the downloaded server (feat(runtime): remove an agent's downloaded runtime only once nothing on the host can still run it #29139). Merged alone, nothing runs an operation, so the only visible change is the message wording.

Why

The Antigravity server writes its sign-in back to its folder every time it refreshes it, so a chat left running would undo a sign-in. A chat left running during Remove would run deleted files. Stopping every process before the change, and refusing new starts while it runs, closes both windows with one fence instead of a lock per operation. Like the common pattern, every path that starts this agent goes through it. Holding each started process until it exits, rather than trusting the list of loaded chats, covers the gap between a start and its attach. Reusing the existing account-change refusal keeps one message for one situation, and older paired Orca versions already understand that reason.

Linked Issue

N/A (maintainer; part of the Antigravity Chat UI stack).

Visual Proof

N/A: nothing triggers the gate until #28650 (sign-in) or #29139 (Remove). The message change is copy only.

Testing

• I manually tested these changes locally

• Automated tests added/updated, or explained why not below

• Through the existing adapter rig: a start under way when an operation begins is aborted before the operation's work runs, a new start during the operation is refused with the account-changing reason, and an operation whose chat stop fails never runs its work. It fails without the adapter hook.

• An operation started while a chat has started but is not yet loaded stops that chat's process before the work runs.

• pnpm tc:node, pnpm tc:web and the ACP and runtime tests passed.

Review

Agent skill upstream boundary

• Not applicable, or this change copies or mechanically translates no upstream skill-installer source, tests, fixtures, registry entries, path tables, comments, or documentation.

Notes

• No wire change: the refusal reuses an existing reason.
• SSH and remote hosts: the gate lives on the host that runs the chats. A restart of that host's Orca ends it.
• Windows: Antigravity chats are not offered there, so the gate never runs.
• PR author: @BrennanKB5

Differences from the common pattern

• Intended: a sign-in change (and later a runtime removal) proceeds only once every process of the agent is proven to have exited; if any cannot be, the change fails and the person can try again. The common pattern waits for its stop without proof of exit. A close that cannot prove exit is not evidence the process is gone, and the change must not replace or delete files under a process that may still use them.
• Intended: the gate is entered by chat starts and conversation copies, the sign-in process runs inside the gated operation itself, and Orca starts no model-listing or background process for this agent. The common pattern hands the same lock to every one of its consumers; the coverage is the same, through Orca's start paths.
• Intended: there is one gate per agent per host, because Orca keeps one sign-in folder per agent per host and has no per-provider instances.

Checklist

• This PR is small and focused
• I explained what changed and why (ELI5, the user-facing before/after, the mechanism, and why over the alternatives)
• Before/after screenshots or videos attached for UI changes, or N/A with reason
• Self-reviewed for correctness, security, and performance
• Cross-platform, SSH/remote, and path/shortcut impact considered (or N/A)
• pnpm lint, pnpm typecheck, pnpm test, and pnpm build pass (or CI will cover; local preferred)

[brennanb2025]

Antigravity chats on one machine share a sign-in, and a chat left running during an account change can write the old sign-in back over the replacement. This PR prepares coordination on the machine running the chats for the later sign-in/sign-out service; ordinary launches retain the parent branch’s behavior. The existing account-change refusal now names the agent instead of always saying Claude.

Three review rounds fixed two cancellation gaps and the adapter’s line-limit failure. Cancelled starts now finish before the stop pass, so it can include a failed startup whose child remains unproven; a failed stop prevents credential changes. Cancellation also reaches the download and extraction needed to start the agent. The final architecture challenger recommends keeping this design, with no new findings in round 3.

Deferred by decision: an interrupted start retains the existing generic retry notice. The follow-on service must use this gate on the machine running the chats and stop every live or exit-unproven child before changing the sign-in.

Verified at 41595874f99: 67 targeted tests, full Node typechecks, lint, code quality, localization and line-limit checks. Local orca-ci-checks passed 22/23; its only failure is the known local Bun version lacking bun check. All required CI checks passed, including packaging, wire compatibility, relay integration and the five Node test shards.

Performance was checked by source tracing; real download latency and resource release were not measured. Electron QA is N/A here because no production action invokes the gate yet; real Google sign-in and the complete account-change flow remain for later layers. No merge was performed.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: f68cbef6-f91f-43c9-9cfc-dcb7bfaae927

📥 Commits

Reviewing files that changed from the base of the PR and between 2117d77 and e62721d.

📒 Files selected for processing: 17

• src/main/acp/acp-conversation-copies.ts
• src/main/acp/acp-launch-gate.ts
• src/main/acp/acp-launch-specs.ts
• src/main/acp/acp-structured-antigravity.test.ts
• src/main/acp/acp-structured-session-adapter.ts
• src/main/native-chat/agent-session-wire/structured-agent-session-failure-text.test.ts
• src/main/native-chat/agent-session-wire/structured-agent-session-pre-spawn-first-answer.test.ts
• src/renderer/src/components/native-chat/agent-session-failure-words-text.ts
• src/renderer/src/i18n/en-runtime-required.json
• src/renderer/src/i18n/locales/en.json
• src/renderer/src/i18n/locales/es.json
• src/renderer/src/i18n/locales/fr.json
• src/renderer/src/i18n/locales/ja.json
• src/renderer/src/i18n/locales/ko.json
• src/renderer/src/i18n/locales/zh.json
• src/shared/agent-session-failure-copy.ts
• src/shared/agent-session-failure-words.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

📝 Walkthrough

The Antigravity ACP launch flow now uses an optional in-memory gate to coordinate starts with operations that stop live chats and retained provider connections. The gate rejects starts during an operation and clears its active state after success or failure. Failure wording and translations now identify the agent whose setup is changing on the host.

Priority: ⬇️ Low

Merge Risk: ⚪ Minimal · up to e6272

The change adds coordination infrastructure that is not yet invoked by any production action, plus clearer wording for setup-change failures. No actionable merge-blocking risk was found.

Pre-merge checks: 5

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main change: pausing an agent's chat starts while shared sign-in changes occur.
Description check		The description is detailed and covers the required explanation, changes, rationale, testing, visual proof, scope, compatibility, and checklist sections. It marks visual proof as not applicable with a…
Docstring Coverage		No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 1…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Description check

Explanation

The description is detailed and covers the required explanation, changes, rationale, testing, visual proof, scope, compatibility, and checklist sections. It marks visual proof as not applicable with a reason and identifies the author as a maintainer for the issue exception. The final command checklist remains unchecked, but the description reports targeted tests and CI results, so the description is mostly complete.

Full details: Docstring Coverage

Explanation

No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 10 files. (7 skipped: 7 unsupported.)

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.}