Skip to content

Antigravity ACP runtime terminates with SIGKILL on pure cgroups v2 Linux (CpuMonitor watchdog timeout) #16343

Description

@ehab-oss

What happened

The Antigravity integration wasn't working for me. Looking at the existing GitHub issues/PRs (such as PR #15746), it seemed others were addressing a different problem that was resolved for them. However, even after updating to the latest version that included their fix, the integration still failed to start on my machine. It turned out I was hitting a separate underlying issue, which we diagnosed during this session.

When attempting to install or start the Antigravity ACP runtime via Settings -> Providers -> Antigravity, T3 Code fails installation validation and reports:
"The downloaded Antigravity runtime could not start in this environment."

Diagnosis

On modern Linux kernels running pure unified cgroups v2 (without legacy cgroup v1 controllers mounted under /sys/fs/cgroup/cpu), Google's official Antigravity ACP binary (agy_acp_server.par, versions 1.1.1 through 1.3.0) terminates with SIGKILL (exit code 137) ~1000 ms after launch.

  1. Missing cgroup v1 mount: The binary embeds Google3 C++ runtime infrastructure (stats_census::internal::CpuMonitor), which calls borg::utils::GetRootCgroupForResource expecting legacy cgroup v1 paths (/sys/fs/cgroup/cpu, cpuacct.usage). On pure cgroup v2 systems, it logs:
    Failed getting Machine CPU Usage through cgroup: Couldn't find mount for subsystem: cpu
  2. Watchdog deadline: An internal 1000 ms timer (kDefaultCpuReadDeadline) arms at startup. When the timer expires without resolving the cgroup subsystem, absl::log_internal::LogMessageFatal and FailureSignalHandler issue a self-sent SIGKILL.
  3. T3 Code validation failure: AntigravityInstallation.validate executes agy_acp_server.par --uid= as a pre-flight sanity test. Because the process is killed at ~1004 ms, T3 Code catches the SIGKILL exit status, rejects the installation, and deletes the extracted runtime directory.

Steps to reproduce

  1. Run T3 Code on a Linux distribution with pure cgroups v2 (e.g. Arch Linux, Omarchy kernel 7.2.x, Fedora default).
  2. Go to Settings → Providers → Antigravity.
  3. Click Install Antigravity (or download and run agy_acp_server.par --uid= directly in a shell).
  4. Observe that the process exits with status 137 (SIGKILL) after ~1 second, and T3 Code displays:
    "The downloaded Antigravity runtime could not start in this environment."

Version

T3 Code 0.0.46-nightly (and 0.0.45)

Environment

OS: Linux x64 (Arch Linux / Omarchy 7.2.5-3-omarchy, unified cgroup v2)
Node: v26.8.2
Desktop / AppImage installation

Evidence

Log from ~/.t3/userdata/logs/server.trace.ndjson:

AntigravityInstallationError: The downloaded Antigravity runtime could not start in this environment.
    at AntigravityInstallation.install ...
  [cause]: AcpTransportError: ACP transport operation read-process-exit-status failed.
  [cause]: PlatformError: Unknown: ChildProcess.exitCode (~/.t3/tools/antigravity-acp/linux-x64/versions/.install-K9sNoQ/runtime/agy_acp_server.par --uid=)
  [cause]: Error: Process interrupted due to receipt of signal: 'SIGKILL'

Diagnostic startup log from agy_acp_server.par:

I1005 03:48:53.743675  init.cc:78] Remote crash gathering hook installed.
I1005 03:48:53.745069  python_stack_size.cc:53] EventManager thread stack size increased to 245760 for non-test Python use.
I1005 03:48:53.746186  cpu-monitor.cc:52] Failed getting Machine CPU Usage through cgroup: Couldn't find mount for subsystem: cpu
[Process terminated after 1000ms by SIGKILL (exit code 137)]

Related issues

PR #15746 (bump Antigravity ACP agent to 1.3.0). PR #15746 added macOS Intel support and bumped the release asset to 1.3.0, but both 1.1.1 and 1.3.0 retain the same Google3 cgroup v1 CpuMonitor watchdog, causing the binary to fail on modern pure cgroups v2 Linux distributions.

Fix applied or workaround

Compiled a lightweight C compatibility library (libtimer_compat.so) that intercepts timer_settime:

#define _GNU_SOURCE
#include <time.h>
#include <string.h>

int timer_settime(timer_t timerid, int flags, const struct itimerspec *new_value, struct itimerspec *old_value) {
    if (old_value) memset(old_value, 0, sizeof(*old_value));
    return 0;
}

Preloading this library via LD_PRELOAD prevents the 1000 ms watchdog from arming while allowing the authentic Google binary to run normally. Wrapping agy_acp_server.par with this preloaded shim and pointing T3 Code's binaryPath to the wrapper allows Antigravity ACP to pass validation, authenticate via OAuth, and handle completions successfully.

Filed by

t3 triage

Activity

  1. ehab-oss commented on Oct 6, 2026

    @ehab-oss
    Author

    Before
    Image
    After
    Image

  2. ehab-oss commented on Oct 10, 2026

    @ehab-oss
    Author

    Update & Resolution

    Following the investigation in #13842 (specifically this comment), the root cause on Arch Linux (Omarchy) was identified:

    1. The system was missing the rtkit package.
    2. Without rtkit, xdg-desktop-portal falls back to RTTimeUSecMax = 0 (busctl --user get-property org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Realtime RTTimeUSecMax returned x 0).
    3. PipeWire (libpipewire-module-rt) queried the portal and clamped RLIMIT_RTTIME to 0:0.
    4. Omarchy's shell and subsequently T3 Code inherited RLIMIT_RTTIME=0.
    5. When Google's agy_acp_server armed its CPU/thread timers, the Linux kernel (posix_cpu_timers_work) immediately terminated the process with SIGKILL (exit code 137).

    Solution Verified

    Installing rtkit and restarting the services resolved the issue completely:

    sudo pacman -S --needed rtkit
    sudo systemctl enable --now rtkit-daemon.service
    systemctl --user restart xdg-desktop-portal.service
    omarchy-restart-shell

    After doing this, RTTimeUSecMax updated to 200000, the inherited zero limit was cleared, and the official Google Antigravity ACP runtime in T3 Code started up, completed OAuth, and loaded models natively without needing any custom shims.

    Closing this in favor of the upstream tracking issue in #13842.

  3. ehab-oss commented on Oct 10, 2026

    @ehab-oss
    Author

    Resolved via rtkit installation as documented in #13842.

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions