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.
- 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
- 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.
- 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
- Run T3 Code on a Linux distribution with pure cgroups v2 (e.g. Arch Linux, Omarchy kernel 7.2.x, Fedora default).
- Go to Settings → Providers → Antigravity.
- Click Install Antigravity (or download and run
agy_acp_server.par --uid= directly in a shell).
- 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
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 withSIGKILL(exit code 137) ~1000 ms after launch.stats_census::internal::CpuMonitor), which callsborg::utils::GetRootCgroupForResourceexpecting 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: cpukDefaultCpuReadDeadline) arms at startup. When the timer expires without resolving the cgroup subsystem,absl::log_internal::LogMessageFatalandFailureSignalHandlerissue a self-sentSIGKILL.AntigravityInstallation.validateexecutesagy_acp_server.par --uid=as a pre-flight sanity test. Because the process is killed at ~1004 ms, T3 Code catches theSIGKILLexit status, rejects the installation, and deletes the extracted runtime directory.Steps to reproduce
agy_acp_server.par --uid=directly in a shell).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:Diagnostic startup log from
agy_acp_server.par: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
CpuMonitorwatchdog, 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 interceptstimer_settime:Preloading this library via
LD_PRELOADprevents the 1000 ms watchdog from arming while allowing the authentic Google binary to run normally. Wrappingagy_acp_server.parwith this preloaded shim and pointing T3 Code'sbinaryPathto the wrapper allows Antigravity ACP to pass validation, authenticate via OAuth, and handle completions successfully.Filed by
t3 triage