[Bug]: Antigravity install fails on Linux x86-64 — official agy_acp_server 1.1.1 is SIGKILLed at startup without a seccomp filter (upstream bug + workaround)

Before submitting

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

Area

apps/server

Steps to reproduce

On Linux x86-64 (Arch Linux in my case), open T3 Code desktop 0.0.42.
Settings → Providers → Antigravity → Install.
The download and extraction succeed, then validation fails.

Expected behavior

The managed Antigravity runtime installs and the provider becomes ready.

Actual behavior

Install fails with "The downloaded Antigravity runtime could not start in this environment." T3 then rolls back and deletes the download.

The root cause is upstream, in Google's binary: the official agy_acp_server 1.1.1 (linux-x86_64) is SIGKILLed (exit 137) about 2–3 s after launch, before any of its Python code runs, unless the process starts with a seccomp filter already installed. It fails the same way outside T3 (./agy_acp_server.par --notices → Killed, exit 137). It runs fine with any seccomp filter present, including one that allows every syscall, e.g. inside podman with the default profile. The full analysis is in Google's tracker:

➡️ google-antigravity/antigravity-cli#1112

This is not the same bug as #11767 / #13076, which share this error message. That one is the self-contained t3 binary rejecting -e in the browser-helper preflight. Here the ACP runtime itself dies, reproduced with no T3 involvement.

Impact

Blocks work completely

Version or commit

0.0.42 (desktop, t3code-bin 0.0.42-2)

Environment

Arch Linux (Omarchy), kernel 7.2.5, glibc 2.44, cgroup v2 only, Intel i7-8550U. Antigravity ACP runtime agy_acp_server_1.1.1 linux-x86_64.

Logs or stack traces

# server.trace.ndjson
AntigravityInstallation.validate Failure: AntigravityInstallationError: The downloaded Antigravity runtime could not start in this environment.

# running the downloaded runtime directly
$ ./agy_acp_server.par --notices; echo $?
Killed
137

Workaround

Launch the runtime through a small wrapper that installs an allow-all seccomp filter before exec, and point T3's Antigravity custom executable path at it. The wrapper must sit in the same directory as agy_acp_server.par and localharness_external, because T3 requires the localharness_external sibling.

Download https://dl.google.com/agy-extensions/releases/linux/agy-acp-server-agy_acp_server_1.1.1-linux-x86_64.zip and extract it to e.g. ~/.local/opt/agy-acp/.
Save this as ~/.local/opt/agy-acp/agy_acp_server and chmod +x it:

#!/usr/bin/python3
# Workaround for google-antigravity/antigravity-cli#1112
import ctypes, os, struct, sys
libc = ctypes.CDLL(None)
libc.prctl(38, 1, 0, 0, 0)  # PR_SET_NO_NEW_PRIVS
insn = ctypes.create_string_buffer(struct.pack('HBBI', 0x06, 0, 0, 0x7fff0000))  # BPF RET ALLOW
class P(ctypes.Structure): _fields_ = [('len', ctypes.c_ushort), ('f', ctypes.c_void_p)]
libc.prctl(22, 2, ctypes.byref(P(1, ctypes.addressof(insn))), 0, 0)  # PR_SET_SECCOMP
here = os.path.dirname(os.path.realpath(__file__))
os.execv(f'{here}/agy_acp_server.par', [f'{here}/agy_acp_server.par', *sys.argv[1:]])

Settings → Providers → Antigravity → binary path: ~/.local/opt/agy-acp/agy_acp_server (absolute path).

With this, T3 reports Antigravity ready (agy_acp_server_1.1.1), and Google sign-in (oauth-personal) works.

Possible improvement in T3

AntigravityInstallation.validate maps every failure to the same generic message, so a SIGKILL, a SIGILL (#11414), an IPv6 problem (#9800) and the -e preflight regression (#11767) all look identical. Including the child's exit code or signal and the last few stderr lines in the error would make these diagnosable from the UI. It could also point users to the custom-executable-path option.

Additional reproduction and a narrower isolation result from another Omarchy laptop. The inherited RLIMIT_RTTIME=0 is sufficient to reproduce the startup SIGKILL here, without changing seccomp.

Environment:

T3 Code desktop 0.0.44-1 (t3code-bin)
Antigravity ACP agy_acp_server_1.1.1, managed release SHA-256 38f62d01b32deb0907b3d39a71ec301fd36369f6ffd1cf262d4af385177f79df
Arch/Omarchy, x86-64, kernel 7.2.7-arch1-Watanare-T2-2-t2
glibc 2.44+r24+g16be1518495f-1

T3's running server process and its child shell both have this in /proc/<pid>/limits:

Max realtime timeout      0                    0                    us

The normal user-systemd-launched process has unlimited for both limits. To isolate that difference, launch the SAME runtime through transient user services, changing only the limit:

# Set AGY_ACP to the full path of the installed agy_acp_server.par.
systemd-run --user --pipe --wait --collect --quiet   -p LimitRTTIME=infinity "$AGY_ACP" --uid= --notices

systemd-run --user --pipe --wait --collect --quiet   -p LimitRTTIME=0 "$AGY_ACP" --uid= --notices

Results:

infinity: exits 0 and prints licenses (3,157,433 bytes).
0: no stdout; systemd-run exits 255. A non-quiet startup reproduction reports code=killed, status=9/KILL, approximately 3 seconds after launch, with only ~167 MiB peak memory.
No kernel OOM event; cgroup memory.events OOM counters are zero.
GLIBC_TUNABLES=glibc.pthread.rseq=0 did not fix the direct launch.

T3's trace records RpcClientDefect: ACP protocol terminated. during RpcClient.initialize, before Google sign-in.

Working workaround: configure T3's Antigravity custom binary path to a launcher using a transient user service with systemd-run --user --pipe --wait --collect --quiet --service-type=exec --expand-environment=no --property=LimitRTTIME=infinity. Preserve the working directory and T3's provider environment, especially GEMINI_HOME, AGY_ACP_FORCE_FILE_STORAGE, TMPDIR, BROWSER, and ANTIGRAVITY_HARNESS_PATH; preserve the required localharness_external sibling. The service manager supplies the normal limit instead of inheriting the zero hard limit.

With this launcher, ACP initialize returns protocol 1, agentInfo.version=agy_acp_server_1.1.1, capabilities and all four auth methods. Closing stdin shuts it down cleanly with exit 0. T3 picked up the custom path. Full Google sign-in / a T3 model turn has not yet been verified; the standalone agy CLI separately answered a test prompt successfully.

This confirms a limit-dependent failure on this machine; it does not yet establish who originally sets the zero hard limit or the internal reason Google's runtime is killed. The seccomp workaround in the original report may affect the same path, but I have not tested that relationship.

Suggested investigation: check inherited RLIMIT_RTTIME on the desktop provider spawn path, and surface the child signal/exit status rather than only the generic ACP termination error. Avoid changing system-wide limits as a workaround.

Related upstream report: google-antigravity/antigravity-cli#1112

Confirming on a second Omarchy machine (T3 0.0.44 t3code-bin, Electron 44.4.2 / Chromium 152.0.7977.130, Hyprland, kernel 7.2.5), and with the newer Antigravity runtime 1.3.0, so it isn't specific to 1.1.1.

On the open question of who sets the zero limit: it's the desktop app's Electron main process. Process chain: systemd --user = unlimited → t3code --ozone-platform=wayland … (main) = 0/0 → embedded server (ELECTRON_RUN_AS_NODE) = 0/0 → agent. T3's source doesn't call setrlimit, so it probably comes from Electron/Chromium init. Spawning the same runtime from ELECTRON_RUN_AS_NODE=1 /usr/lib/t3code/t3code launched from a normal shell works, so it's specifically the desktop main process's tree.

Minimal repro without T3: prlimit --rttime=0:0 ./agy_acp_server.par --uid= gets SIGKILL immediately; without prlimit it answers initialize in ~1.5 s.

Simplest workaround: t3 service install (the systemd user unit gets RLIMIT_RTTIME=unlimited) and use the web UI, so no wrapper is needed. Confirmed working: Antigravity installs, signs in and runs through the service.

Found where the zero limit comes from on Omarchy. It is not Electron or T3 Code.

xdg-desktop-portal started before rtkit was installed. Its Realtime portal then reports RTTimeUSecMax 0:
busctl --user get-property org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Realtime RTTimeUSecMax → x 0
PipeWire's libpipewire-module-rt asks the portal first and sets RLIMIT_RTTIME to that value, soft and hard. A plain pw-mon started from a systemd-run --user unit with an unlimited limit ends at 0/0.
Omarchy's shell (quickshell) is a PipeWire client, so it ends at 0/0. Its parent, omarchy-launch-shell, is unlimited.
Apps started from the launcher inherit it: T3 Code, Slack, Chromium, Zed. A fresh Chromium started outside the shell stays unlimited, with or without rtkit reachable.

Host fix: install rtkit, run systemctl --user restart xdg-desktop-portal (it then reports 200000), run omarchy-restart-shell, then relaunch T3 Code. After the portal restart, a new PipeWire client gets 200000/200000. Under that limit, a non-realtime process that arms a per-thread CPU timer is no longer killed.

The zero limit kills more than Antigravity. In agent-run test suites it SIGKILLed vitest workers, Chrome and CLI children. A signal:signal_generate trace showed the kernel sending the signal from posix_cpu_timers_work. A fix scoped to Antigravity (#13230) leaves other children exposed. T3 could detect the zero limit at startup and warn.

Environment: Arch Linux (Omarchy), kernel 7.2.5, Hyprland, PipeWire, T3 Code nightly 0.0.46 (Electron 44.4.2).

Navigation Menu

Repository navigation

[Bug]: Antigravity install fails on Linux x86-64 — official agy_acp_server 1.1.1 is SIGKILLed at startup without a seccomp filter (upstream bug + workaround) #13842

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Workaround

Possible improvement in T3

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Antigravity install fails on Linux x86-64 — official agy_acp_server 1.1.1 is SIGKILLed at startup without a seccomp filter (upstream bug + workaround) #13842

Description

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Workaround

Possible improvement in T3

Activity

timwalex-oss commented on Oct 1, 2026

mluengas commented on Oct 4, 2026

ElbertePlinio commented on Oct 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions