Skip to content

[Bug]: Antigravity Install never starts; Setup control is easy to miss and disabled until install state loads #14303

New issue
New issue
Closed as not planned
Closed as not planned
[Bug]: Antigravity Install never starts; Setup control is easy to miss and disabled until install state loads#14303
Labels
bugSomething is broken or behaving incorrectly.needs more infoInitial triage showed no bug. Awaiting more infovia-triageFiled through npx t3 triage

Description

@JonathanPitre
JonathanPitre
opened on Sep 29, 2026

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

  1. On Linux x64, launch T3 Code desktop AppImage 0.0.40 (this host: Arch, kernel 7.2.3, AMD Ryzen AI 9 HX 370). t3code-bin is not installed.
  2. Settings → Providers → enable Antigravity. Sign-in method is Google account. Binary path is empty.
  3. The sidebar shows Not found with “Antigravity is not installed. Install it in this environment…”.
  4. The visible form is the Runtime section (Sign-in method, API key). Install Antigravity lives in the Setup section above that form.
  5. ~/.t3/userdata/logs/server.trace.ndjson for that session has AntigravityInstallation.resolve failures and no AntigravityInstallation.start, install, or validate spans. ~/.t3/tools/antigravity-acp was never created.

Expected behavior

Choosing Install Antigravity starts provider.install.start and downloads Google’s ACP runtime (agy_acp_server.par plus localharness_external) into ~/.t3/tools/antigravity-acp/linux-x64/.

Actual behavior

The recorded session never starts the download. The Install control is easy to miss because it is in Setup, above the Runtime form the screenshot shows. In ProviderSetupSection, that button is also disabled while installation === null (install-state subscription not loaded yet) and start/cancel used reportFailure: false, so a failed click looks like a no-op.

This is not the Antigravity IDE. A local IDE install does not satisfy resolve.

This is also not #13842 on this machine. The pinned linux-x64 zip agy_acp_server_1.1.1 (sha256 38f62d01b32deb0907b3d39a71ec301fd36369f6ffd1cf262d4af385177f79df) was downloaded and agy_acp_server.par --notices exited 0. #13842’s SIGKILL (exit 137) was on an Intel i7-8550U with desktop 0.0.42. Do not treat this report as a duplicate of that issue or of #9413 (closed; old RC zip 404, and that click did reach the server).

Impact

Blocks work completely

Version or commit

Desktop AppImage 0.0.40 (PR 10893). Source checkout includes the Antigravity ACP installer pinned to agy_acp_server_1.1.1.

Environment

Arch Linux, kernel 7.2.3-arch1-3, AMD Ryzen AI 9 HX 370 (AVX present). T3 AppImage 0.0.40. t3code-bin not installed, so this was not compared with desktop 0.0.42.

Logs or stack traces

AntigravityInstallationError: Antigravity is not installed. Install it in this environment or set a custom executable path.
  at AntigravityInstallation.resolve
  at AntigravityDriver.makeRuntime
  at checkAntigravityProvider

No provider.install.start span in ~/.t3/userdata/logs/server.trace.ndjson.

Direct preflight, outside T3:

sha256 agy-acp-server-agy_acp_server_1.1.1-linux-x86_64.zip
38f62d01b32deb0907b3d39a71ec301fd36369f6ffd1cf262d4af385177f79df
agy_acp_server.par --notices
exit 0

Workaround

Scroll to Setup (above Runtime) and use Install Antigravity once the button is enabled. Or set Binary path to an extracted agy_acp_server.par that sits next to localharness_external.

Suggested product fix: keep Install enabled while install-state is still loading, show “Checking the Antigravity runtime.”, report install start/cancel failures, and point the “Not found” message at Setup → Install Antigravity.

Activity

  1. juliusmarminge commented on Sep 29, 2026

    @juliusmarminge
    juliusmarminge
    on Sep 29, 2026
    Member

    Triage

    Confirmed on main (d2c9281b81) and in desktop 0.0.40. This session never started an install. It is not #13842 and not #9413.

    The sidebar Not found line is the health check. checkAntigravityProvider calls AntigravityInstallation.resolve, which returns "Antigravity is not installed. Install it in this environment or set a custom executable path." when there is no active.json and no runtime on PATH. That probe does not call ProviderInstallation.start. A session that never hits Install Antigravity has resolve spans only, no provider.install.start / install / validate spans, and never creates ~/.t3/tools/antigravity-acp.

    The linux-x64 agy_acp_server_1.1.1 hash in the report matches apps/server/src/provider/antigravityRelease.ts. --notices exiting 0 on this Ryzen host is enough to keep it separate from #13842, where the same zip is SIGKILLed after a download that did start. #9413 reached AntigravityInstallation.install, and the pinned runtime has since moved to 1.1.1 (#9509).

    The button is easy to miss. In ProviderInstanceCard, Setup (which contains Install Antigravity) sits above the Runtime form (Sign-in method, API key, Binary path). The install row inside Setup is also titled Runtime (ProviderSetupSection), so the form below is a second Runtime section.

    Until providerInstallState emits, the button is disabled (installation === null) in ProviderSetupSection. The same condition is in 0.0.40. SubscriptionRef.changes replays the current idle snapshot, so this is the wait for the first event, not a permanent lock. Auth already says "Reading sign-in status." while its snapshot is null. Install does not: with an empty binary path it falls through to "Not installed." on main (on 0.0.40, "Install the official Antigravity runtime before signing in.") and the button stays disabled. A failed subscription is different: installQuery.error disables the actions and shows the alert plus Retry setup status.

    reportFailure: false on start/cancel does not swallow a click that actually runs. runCommand still writes a non-interrupted failure into the section alert. The no-op is the disabled button.

    The workaround in the report is right: Setup → Install Antigravity after the button enables, or set Binary path to an agy_acp_server.par next to localharness_external. Updating past 0.0.40 does not change this. ProviderInstallation.start already no-ops when an install is in progress, so the useful fix is a loading status (and a Not found detail that names Setup → Install Antigravity), not a second installer.

  2. juliusmarminge
    added
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Sep 29, 2026

  3. JonathanPitre commented on Oct 15, 2026

    @JonathanPitre
    JonathanPitre
    on Oct 15, 2026
    Author

    Verification against latest nightly

    Still present on latest nightly. I checked main at 339179f5 (Oct 15) and nightly 0.0.46-nightly.20261014.3132. The disabled logic from the Sep 29 triage is unchanged.

    Evidence in apps/web/src/components/settings/ProviderSetupSection.tsx on main:

    • Line 253: Install button uses disabled={actionsDisabled || installation === null || authActive}.
    • Lines 135-150: installationStatusMessage has no branch for installation === null. It falls through to "Not installed.". "Checking the downloaded runtime." only covers the verifying phase.
    • Line 134: actionsDisabled covers pending and query error only. The null case is separate on line 253.
    • History: last functional change was 4d16e6bc (Sep 12). fded2cac (Oct 12) touched layout only. No fix for the null disabled state landed after Sep 29.
    • Runtime bump 4dbc0129 (Oct 5, 1.1.1 to 1.3.0 in apps/server/src/provider/antigravityRelease.ts) does not touch this UI path. The UX bug is version independent.

    This was verified by code inspection on main, not by running desktop nightly here. A runtime repro on nightly still needs the steps below.

    Duplicate check

    No duplicate with the same mechanism was found. Searched antigravity install, Antigravity is not installed, and Setup Install Antigravity across open and closed issues.

    Closest but distinct:

    #14303 remains the only report of Install never starting because the Setup control is missed and disabled while install state loads.

    Diagnostics needed to fix

    For anyone reproducing on nightly, please attach:

    • Nightly version and commit. Example: output of the About panel or t3 --version plus the nightly tag.
    • Fresh ~/.t3/userdata/logs/server.trace.ndjson filtered for AntigravityInstallation.resolve, provider.install.start, install, and validate spans.
    • Screenshot of Settings, Providers, Antigravity showing both the Setup section above and the Runtime form below. Note whether Install shows Not installed. with a disabled button.
    • Provider panel state: value of Binary path, Sign in method, and whether Retry setup status or an alert is visible. That distinguishes installation === null wait from installQuery.error.
    • Environment: OS, kernel, CPU, install source (AppImage, t3code-bin, self built), and whether ~/.t3/tools/antigravity-acp exists.
    • Contents of ~/.t3/tools/antigravity-acp if present, or confirmation it was never created.

    Minimal repro on nightly:

    1. Fresh profile or new environment with no active.json and no runtime on PATH.
    2. Open Settings, Providers, enable Antigravity. Leave Binary path empty.
    3. Observe Setup, Runtime row before providerInstallState emits. Record button enabled state and status text.
    4. Wait for first emission, then click Install Antigravity. Check trace for provider.install.start.

    Suggested fix restated

    Keep Install enabled while install state loads, or show an explicit loading status. Suggested text: Checking the Antigravity runtime. Point the Not found detail at Setup, Install Antigravity. Report start and cancel failures instead of using silent no op paths. The install in progress guard in ProviderInstallation.start already exists, so a second installer is not needed.

    Workaround stays valid: use Setup, Install Antigravity after the button enables, or set Binary path to an extracted agy_acp_server.par next to localharness_external.

  4. juliusmarminge commented on Oct 22, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 22, 2026 – with GitCafe Production
    Member

    Tested current main b5a226e49c on Linux x86_64 with vp run dev, an isolated worktree home, and Chrome at 1280 × 800. The database was seeded with stopped threads; Antigravity was a newly added instance with Google account selected, an empty Binary path, and no downloaded runtime.

    In Settings → Providers I enabled Antigravity, saw “Not found”, then used Setup → Install Antigravity. The button was enabled after setup status loaded. The UI advanced to “Downloading 27.3 MB of 333.7 MB” and created the isolated tools/antigravity-acp/linux-x64 directory. I cancelled the download after confirming it started. Trace excerpt:

    ws.rpc.provider.install.start
rpc.method: provider.install.start
exit: Success
durationMs: 33.252569

    I could not reproduce a persistent failure to start. Switching away and back also encountered a disabled “Not installed.” state during connection instability, followed by “Reconnect fs-37”; that does not isolate the initial install-state delay. The loading text/discoverability concern remains separate from a download that never starts. This was web verification, not the Arch AppImage.

    Please provide the current affected version and a recording from opening Antigravity settings through the disabled period, including how long it lasts, whether “Retry setup status” appears, and whether Install becomes enabled after waiting. Include the matching provider.install.start / AntigravityInstallation trace excerpt after attempting the click. That will distinguish the initial snapshot wait, a connection/subscription failure, and an install request failure.

    No matching duplicate found in the paged open-issue scan over the last 90 days.

    Ready to install after setup status loaded

    Antigravity download started on current main

  5. juliusmarminge
    added
    needs more infoInitial triage showed no bug. Awaiting more info
    on Oct 22, 2026

  6. github-actions commented on Oct 29, 2026

    @github-actions
    github-actionsBot
    on Oct 29, 2026 – with GitHub Actions
    Contributor

    Closing: no reply in 7 days after we asked for more information. Comment with the missing details and we will reopen.

  7. github-actions
    closed this as not plannedon Oct 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.needs more infoInitial triage showed no bug. Awaiting more infovia-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions