Please notice that I used Gemini to solve this problem on my Ubuntu laptop, and the text below is a summary of the problem and solution that Gemini wrote.
Description:
Environment
- OS: Ubuntu 24.04 LTS (x86_64) / Debian-based Linux
- Agent:
antigravity-acp (v_1.1.1)
- Host Editor: Zed Editor via Agent Client Protocol (ACP)
Problem Description
When antigravity-acp is launched via Zed on Ubuntu or Debian-based systems, the underlying server binary (agy_acp_server.par) immediately crashes with a fatal check failure during initialization, causing the agent to silently fail or hang.
Steps to Reproduce
- Install
antigravity-acp via the ACP Registry on an Ubuntu or Debian system.
- Trigger the agent startup in Zed (e.g., initiating Google authentication).
- Alternatively, invoke the binary directly from terminal:
~/.local/share/zed/external_agents/registry/antigravity-acp/v_1.1.1*/agy_acp_server.par --debug
Observed Output / Crash Log
F0916 11:20:50.742562 45338 init_google.cc:402] Check failed: LookupGIDByGroupName(groupname, &new_gid) Group nobody not found
*** Check failure stack trace: ***
@ 0x62cf2403c124 absl::log_internal::LogMessage::Flush()
@ 0x62cf2f5e9ee8 SwitchGroup()
@ 0x62cf2f5e8c1f ChangeRootAndUser()
@ 0x62cf2f5eb76e RealInitGoogle()
@ 0x62cf2f0647de Run()
@ 0x62cf2f0640db google3_base_python_clif_googleinit_clifwrap::wrapRun()
@ 0x62cf2454aee8 PyObject_Vectorcall
@ 0x62cf2553ca4d _PyEval_EvalFrameDefault
@ 0x62cf2552e8b1 _PyEval_Vector
@ 0x62cf2723e45f PyEval_EvalCode
@ 0x62cf2fcd25c9 builtin_exec
@ 0x62cf2454b027 PyObject_Vectorcall
@ 0x62cf255343e4 _PyEval_EvalFrameDefault
@ 0x62cf2552e8b1 _PyEval_Vector
@ 0x62cf24b62782 PyObject_CallMethod
@ 0x62cf2f374165 devtools::python_launcher::Launcher_Main()
@ 0x7a8e6282a1ca (unknown)
@ 0x7a8e6282a28b __libc_start_main
@ 0x62cf27b4339a _start
Aborted (core dumped)
Root Cause
In init_google.cc, the default execution parameters specify --uid=nobody and --gid==uid (=nobody).
- On Red Hat / CentOS distributions, the default primary group for
nobody is nobody.
- On Debian and Ubuntu distributions, the user
nobody belongs to primary group nogroup (GID 65534). A group named nobody does not exist by default.
When LookupGIDByGroupName("nobody", &new_gid) executes on Ubuntu/Debian, it fails the assertion and terminates the process via SIGABRT.
Suggested Fixes
-
Registry Manifest / Launch Command Fix (Recommended):
Update the registry execution manifest for antigravity-acp to pass --gid=nogroup (or omit the switch where unnecessary) on Linux platforms to ensure compatibility with standard Debian/Ubuntu environments.
-
Upstream Binary Fix:
Update init_google.cc to query getpwnam("nobody")->pw_gid or fall back to nogroup when GID 65534 is resolved.
User-Side Workaround
Until addressed in the manifest or binary, users on Debian/Ubuntu can work around the crash by manually aliasing GID 65534 to group name nobody:
sudo groupadd -g 65534 nobody -o
Please notice that I used Gemini to solve this problem on my Ubuntu laptop, and the text below is a summary of the problem and solution that Gemini wrote.
Description:
Environment
antigravity-acp(v_1.1.1)Problem Description
When
antigravity-acpis launched via Zed on Ubuntu or Debian-based systems, the underlying server binary (agy_acp_server.par) immediately crashes with a fatal check failure during initialization, causing the agent to silently fail or hang.Steps to Reproduce
antigravity-acpvia the ACP Registry on an Ubuntu or Debian system.Observed Output / Crash Log
Root Cause
In
init_google.cc, the default execution parameters specify--uid=nobodyand--gid==uid(=nobody).nobodyisnobody.nobodybelongs to primary groupnogroup(GID65534). A group namednobodydoes not exist by default.When
LookupGIDByGroupName("nobody", &new_gid)executes on Ubuntu/Debian, it fails the assertion and terminates the process viaSIGABRT.Suggested Fixes
Registry Manifest / Launch Command Fix (Recommended):
Update the registry execution manifest for
antigravity-acpto pass--gid=nogroup(or omit the switch where unnecessary) on Linux platforms to ensure compatibility with standard Debian/Ubuntu environments.Upstream Binary Fix:
Update
init_google.ccto querygetpwnam("nobody")->pw_gidor fall back tonogroupwhen GID65534is resolved.User-Side Workaround
Until addressed in the manifest or binary, users on Debian/Ubuntu can work around the crash by manually aliasing GID
65534to group namenobody: