Using the IDE. This is a regression; it worked until recently (≤ version 2.1.1).
In sandboxed mode, every terminal command the agent tries fails.
Ran command: echo foo
The command failed with the following error:
error executing cascade step: CORTEX_STEP_TYPE_RUN_COMMAND: read unix @ -> @: recvmsg: connection reset by peer
(Separately, getting AG to work on Ubuntu 24 is painful to begin with. One has to muck around with AppArmor and permissions on the bundled chrome-sandbox binary; with that however it did work robustly (access limitations too) until this regression.)
Settings:
Agent terminal execution broken on Linux since 2.1.1 — “recvmsg: connection reset by peer” (sandbox remount failure), all standard mitigations already ruled out
Antigravity IDE Version: 2.1.1
VSCode OSS Version: 1.107.0
Commit: e0b7a2bcf575cfba10528c4e7c10bd3ce2d7769a
Date: 2026-06-17T22:39:43.962Z
Electron: 39.2.3 / Chromium 142.0.7444.175 / Node.js 22.21.1
OS: Ubuntu 24.04.4 LTS, kernel 6.17.0-35-generic (x86_64)
Symptom
Every command the agent tries to run (e.g. git status) fails immediately with:
“Hubo un error de conexión al ejecutar el comando.”
The application log (logs/<session>/ls-main.log) shows the underlying failure:
E0716 ... log.go:398] failed to check terminal shell support: internal: internal error
sbox: remount /proc/cpuinfo: operation not permitted
E0716 ... log.go:398] error executing cascade step: CORTEX_STEP_TYPE_RUN_COMMAND: read unix @ -> @: recvmsg: connection reset by peer
The agent’s internal sandbox wrapper (sbox) appears to create a mount namespace and attempt to remount /proc/cpuinfo (presumably to mask host info before running the command). That remount fails with EPERM, which kills the sandboxed helper process and resets the local IPC socket — hence the recvmsg: connection reset by peer surfaced to the UI. The agent then repeatedly retries and ultimately asks the user to run the command manually instead.
What I already ruled out (this is not a config/permissions issue on my end)
kernel.unprivileged_userns_clone = 1 (enabled)kernel.apparmor_restrict_unprivileged_userns = 0 / ..._unconfined = 0 (no AppArmor userns restriction)- AppArmor profile for the language server process and for a normal shell: both
unconfined
chrome-sandbox helper binary: correct -rwsr-xr-x root root (setuid root, 4755) — not a broken-permissions issue- No seccomp filters,
NoNewPrivs=0 on the language server process
/proc/sys/user/max_user_namespaces = 126599 (plenty of headroom, not exhausted)- Root filesystem mounted
rw,relatime (no nosuid/nodev restricting this)
- Manually reproduced the equivalent operation outside Antigravity and it succeeded:
unshare --user --map-root-user --mount --pid --fork -- mount --bind /proc/cpuinfo /proc/cpuinfo → exit code 0
- Not a systemd app-scope confinement issue:
NoNewPrivs, Seccomp, and capability sets on the running language-server process are unrestricted
- Reproduced across a full quit+relaunch of the IDE (fresh extension host, new PIDs) — same failure
update.mode was set to none; switched to default and ran “Check for Updates” manually — already on the latest version, no update available
So on this machine, every kernel/AppArmor/systemd/file-permission precondition the sandbox needs is already satisfied, and the exact syscall pattern it needs (bind-mount + remount inside a fresh user+mount namespace) works fine when done manually outside of Antigravity. The failure is isolated to Antigravity’s own sbox component.
When it started
This started for me specifically after updating to 2.1.1 — command execution worked before that. This matches other reports in this forum of a regression introduced in the 2.0 → 2.1.x range (see “Since antigravity IDE 2.0, Agent can’t use terminal ‘connection reset by peer’” and “Linux sandbox: agent unable to run commands” threads).
Questions for the team
- Is this the same known regression being tracked internally, and is there an ETA for a fix?
- Is there any supported way to disable/bypass the command sandbox (a setting, not just the “manual approval” fallback the agent already falls back to, which currently just asks the human to run the command themselves)?
- Is downgrading to a pre-2.1.1 build a safe/supported workaround in the meantime, and if so, where can we get an older installer?
Happy to provide full logs (ls-main.log, ptyhost.log, cloudcode.log) or run additional diagnostics if useful.
Bump. This issue is still very real.
Follow-up / workaround that worked for me (Ubuntu 24.04):
For anyone still hitting “agent unable to run commands” — in my case the fix had nothing to do with AppArmor or the apparmor_restrict_unprivileged_userns sysctl. The root cause was simpler: the Agent was in Sandboxed security mode, and on Ubuntu 24.04 that sandbox fails to initialize (very likely the same userns/AppArmor interaction discussed above), so the agent can’t spawn any process.
Fix: Settings → Permissions → Agent security mode, switched from Sandboxed to Full access. Agent could run terminal commands immediately after. No kernel policy changes, no sysctl edits, no touching AppArmor profiles.
Important trade-off, stated plainly: Full access means exactly what it says — the agent has full access to your machine and to external resources, with no sandbox. This is a workaround, not a fix: you’re not repairing the sandbox, you’re removing it and accepting the risk. If you run anything sensitive on that machine (credentials, personal services, etc.), weigh that before flipping the switch. I’d still love to see the Sandboxed mode actually work on Linux rather than having to disable it.
