[Bug]: Antigravity provider session never opens on Linux desktop — Electron tree sets RLIMIT_RTTIME=0, agy_acp_server 1.3.0 self-SIGKILLs (confirmed root cause + wrapper) #16744

Area

apps/server (Antigravity provider spawn path)

Summary

Confirmed root cause: the Electron main process tree sets RLIMIT_RTTIME=0, and agy_acp_server.par self-SIGKILLs when the real-time budget is zero. This is the cause identified in #13842, re-verified here on T3 0.0.46-nightly.20261006.2752 with the newer Antigravity runtime 1.3.0, and confirmed for the plain desktop AppImage path (not only t3code-bin service installs).

A working launcher that fixes it is included below. This report is not a duplicate of #13842 in scope: it reproduces the failure without any T3 process involved (direct shell launch), and confirms the workaround for the desktop AppImage build.

Steps to reproduce

1. T3 Code desktop (AppImage) on Linux, Antigravity enabled.
2. Send any prompt with an Antigravity model.
3. Every initialize fails, surfacing as:

Failed to open antigravity provider session provider-session:provider-instance:antigravity:thread:<threadId>:<runId>.

Actual behavior

AcpTransportError on every attempt. T3 spawns agy_acp_server.par --uid= with an empty --uid, the process is SIGKILLed, and T3 surfaces only the generic message. No retry recovers it.

Cause chain from ~/.t3/userdata/logs/server.trace.ndjson:

AcpTransportError: ACP transport operation read-process-exit-status failed.
  [cause]: PlatformError: Unknown: ChildProcess.exitCode (.../agy_acp_server.par --uid=)
    [cause]: Error: Process interrupted due to receipt of signal: 'SIGKILL'

Provider event log shows initialize started/failed in ~3.5 s on every retry.

Key finding: not T3-specific, and not the empty --uid

The empty --uid= in T3's spawn line is a red herring. The binary dies with no --uid flag at all, and dies identically outside T3:

# clean shell, no T3 process involved
$ ./agy_acp_server.par < /dev/null; echo $?
Killed
137

$ ./agy_acp_server.par --uid=chakresh < /dev/null; echo $?
Killed
137

# same binary, RTTIME=0 explicitly -> immediate kill
$ prlimit --rttime=0:0 ./agy_acp_server.par --uid= --notices; echo $?
Killed
137

Memory climbs normally to ~287 MB RSS and then it dies at ~4 s. There is no kernel OOM event, no audit/apparmor/seccomp denial in dmesg or the journal, and no stdout/stderr output. On this cgroup v2-only host, the cpu-monitor.cc:52 line quoted in #16343 does not appear, so that specific watchdog path is not what kills it here.

The working desktop/shell process tree is confirmed by the inherited limit:

$ prlimit | grep -E 'RTTIME|RTPRIO'
RTPRIO  max real-time priority   0   0
RTTIME  timeout for real-time tasks  0   0 microsecs

Verification that RLIMIT_RTTIME is the trigger

Launching the same unmodified binary through a transient user service that supplies a normal limit works and streams the full license text:

$ systemd-run --user --pipe --wait --collect --quiet \
    -p LimitRTTIME=infinity \
    ./agy_acp_server.par --notices > out.txt
# exit 0, out.txt = 3,158,071 bytes

Workaround launcher

Preserve the working directory, the localharness_external sibling (T3 validates it), and T3's provider environment — notably GEMINI_HOME, AGY_ACP_FORCE_FILE_STORAGE, TMPDIR, BROWSER, ANTIGRAVITY_HARNESS_PATH. Point Settings → Providers → Antigravity → custom binary path at a wrapper such as:

#!/usr/bin/env bash
# agy-acp-wrapper.sh — clears the zero RLIMIT_RTTIME inherited from Electron
exec systemd-run --user --pipe --wait --collect --quiet \
  --service-type=exec --expand-environment=no \
  -p LimitRTTIME=infinity \
  -p WorkingDirectory="$PWD" \
  -E GEMINI_HOME -E AGY_ACP_FORCE_FILE_STORAGE -E TMPDIR \
  -E BROWSER -E ANTIGRAVITY_HARNESS_PATH \
  /path/to/agy_acp_server.par "$@"

Impact

Antigravity is completely unusable as a non-root Linux desktop user. In this installation 0 of 7 Antigravity runs ever opened a provider session, so there is no working configuration to fall back to.

Note: auth itself is healthy. The stored OAuth refresh token returns HTTP 200 from https://oauth2.googleapis.com/token, and the standalone agy CLI works (agy models lists all models, agy -p answers prompts). Only the T3-managed ACP runtime is affected.

Version or commit

T3 Code 0.0.46-nightly.20261006.2752 (desktop AppImage T3-Code.AppImage)

Environment

• Arch Linux / Omarchy, kernel 7.2.x, x86_64, 16 vCPU, 14 GiB RAM
• cgroup v2 unified only (stat -fc %T /sys/fs/cgroup = cgroup2fs), no /sys/fs/cgroup/cpu
• glibc 2.44, Tailscale 1.102.3
• Antigravity managed runtime agy_acp_server.par 1.3.0 (releaseId 9fb60956af0a9d76220a4db91ca9ac88e2a2372ad68f985ab5fceace6b825b96)
• Node v26.7.0, Electron/Chromium 152 (Omarchy)

Related

• [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 — same underlying limit bug, reported against 0.0.42/agy_acp_server 1.1.1
• Antigravity ACP runtime terminates with SIGKILL on pure cgroups v2 Linux (CpuMonitor watchdog timeout) #16343 — SIGKILL attributed to a cgroup v2 CpuMonitor watchdog; that log line does not appear in this reproduction

Upstream: google-antigravity/antigravity-cli#1112