AI 程式開發工具
Gemini CLI 0.58 Blocks macOS Sandbox Access to Container Daemons, Closing Host Path That Could Bypass File Boundaries
The new release blocks sockets, executables, and IPC interfaces for container runtimes such as Docker, OrbStack, and Colima across all built-in Seatbelt profiles. The update also fixes write-policy configuration, the safety checker, and A2A cancellation state, but custom installation paths and existing workflows still require separate validation.
Google released Gemini CLI 0.58.0 on September 1. Its most consequential change tightens the boundary between the macOS Seatbelt sandbox and local container runtimes. Previously, even when an agent was restricted to writing within a project directory, processes inside the sandbox could still access daemon sockets for Docker Desktop, OrbStack, Colima, or Rancher Desktop. If broad process execution, file-read access, and outbound network access were also permitted, a process could ask the daemon to start a container and then mount the host filesystem through VirtioFS, bypassing the original Seatbelt file rules.
Version 0.58.0 applies deny rules to the dynamic profile builder and all six built-in static profiles. The blocked targets include `/var/run/docker.sock`; Docker, Colima, OrbStack, and Rancher Desktop sockets under the user directory; the `docker`, `dockerd`, `docker-compose`, `podman`, `colima`, and `orb` executables in common installation locations; and related Mach/XPC service lookups and POSIX shared memory. The merged changes also add profile-generation and rule-invariant tests. The two test suites listed by the maintainers are expected to pass a combined 52 test cases.
The release also fixes write-policy configuration: the top-level safety checker is now explicitly included in the configuration, preventing it from being skipped because of the configuration structure. The A2A server now clears cancellation errors left over from the previous turn when a new message turn begins. History rollback and retry prompts have also been adjusted to reduce the chance that a single failure will continue contaminating subsequent agent turns. These are not model capability upgrades, but reliability fixes for tool execution, state recovery, and authorization decisions.
Teams using macOS with sandboxing enabled should prioritize the upgrade, especially in environments that also run Docker Desktop or a compatible daemon. However, the rules depend on known sockets and common binary paths, so custom container runtimes, nonstandard installation locations, and unlisted IPC channels still require independent threat modeling. Workflows that previously required an agent to control Docker may also fail after the upgrade; disabling the entire sandbox should not be treated as a general solution without first assessing the risks.