Three aliases, one posture

Fixing a mount-namespace bug that broke git worktrees across autonomous CLI aliases, dropping phantom sandboxes, and persisting workspace ownership across container rebuilds.

The devcontainer defines shell aliases for its three developer CLIs (Claude Code, OpenAI Codex, Google Antigravity), allowing agents to run in an autonomous mode for fast, unattended development. When trying to run parallel workflows under the autonomous Claude Code alias, git worktree creation failed every single time with an error claiming git metadata could not be resolved. Tracing why an autonomy flag broke worktrees led to an audit of all three aliases, revealing that each tool was running under broken assumptions about its sandbox and permission boundaries.

The sandbox that broke the worktree#

Passing the blanket permission-bypass flag to Claude Code activated its own internal Bubblewrap sandbox for subprocess isolation. But that sandbox’s isolated mount namespace diverged from the host container’s filesystem view. When git creates an isolated worktree, it verifies device and inode identities to vouch that the new worktree belongs to the trusted repository checkout. Inside the mount namespace, those inode checks failed to match, causing git to reject the worktree creation outright. The fix switched the alias to a classifier-based semantic permission mode, which evaluates proposed actions against safety rules without triggering the subprocess sandbox.

Dropping the phantom boundaries#

Investigating the other two CLIs uncovered equally misleading configurations. Codex’s alias had been configured with approval set to bypass all human checkpoints, even though the tool provides an intermediate tier where the model itself escalates risky actions while operating within its verified Linux sandbox. More surprisingly, Antigravity’s alias paired permission skips with a sandbox flag that hands-on testing proved was entirely cosmetic: once shell commands were permitted, the sandbox provided no containment boundary whatsoever. Rather than retaining a flag that offered false reassurance, the sandbox flag was dropped completely in favor of a curated, manually applied command allowlist.

flowchart TD
  accTitle: Three CLI aliases mapping to distinct autonomous checkpoints
  accDescr: Claude Code relies on a semantic classifier. Codex uses model-directed escalation inside a verified Bubblewrap sandbox. Antigravity relies on an explicit command allowlist without a phantom sandbox.

  A["Autonomous CLI aliases"] --> B["Claude Code<br/>(auto permission mode)"]
  A --> C["OpenAI Codex<br/>(on-request approval)"]
  A --> D["Google Antigravity<br/>(accept-edits mode)"]

  B --> E["Semantic classifier<br/>(avoids sandbox trigger)"]
  C --> F["Model escalation +<br/>Bubblewrap sandbox"]
  D --> G["Curated allowlist<br/>(no phantom sandbox)"]

  class E,F,G accent
Three developer CLIs using distinct safety mechanisms to maintain an autonomous risk posture.

Reaping zombies and persisting trust#

While diagnosing the subprocess lifecycles, an inspection of the container process tree surfaced an unrelated operational gap: 149 zombie processes had accumulated across Git, Node, and shell invocations. The devcontainer’s entrypoint does not reap orphaned child processes when parent tasks exit. Adding a minimal init process to the container configuration ensured orphaned processes get reaped cleanly upon termination.

# .devcontainer/docker-compose.yml
services:
  devcontainer:
    init: true

After rebuilding the container with the updated aliases, running an autonomous session still surfaced an intermittent failure. Docker Desktop’s bind mounts occasionally tripped git’s dubious-ownership safety check on the workspace directory, even when user ownership matched. Because user configuration lives on an ephemeral container filesystem rather than a named volume, manually added exceptions vanished on every container rebuild. Setting the safe directory exception automatically during container creation established permanent workspace trust on boot. With phantom sandboxes retired, zombie processes reaped, and workspace trust persisted, the workbench provides dependable unattended automation without pretending barriers exist where they do not.