Configurar políticas del entorno aislado

Que una ejecución de agente esté en un entorno aislado se decide en el servidor, al arrancar (--sandbox). El interruptor Activar sandboxing y el selector Backend de Ajustes → Servidor → Diagnóstico y privacidad son preferencias que se guardan en tu dispositivo. La detección de host de la tarjeta Aislamiento informa de qué puede envolver el host del servidor.

Dos controles llegan a una ejecución y esta guía cubre ambos: las reglas de acciones de Ajustes → Espacio de trabajo → Permisos de agentes, que deciden qué puede enviar, abrir o alcanzar un agente, y el propio flag --sandbox del servidor.

Qué limita una ejecución de agente

Seis cosas sujetan a un agente. La primera es el entorno aislado del sistema operativo y es la única condicional: las otras cinco se aplican en cualquier host.

Frontera	Qué hace
El entorno aislado del sistema operativo	Seatbelt en macOS, bubblewrap en Linux y WSL2. Envuelve la CLI de Claude Code, los adaptadores ACP y la herramienta `bash` del arnés. Ausente en Windows y en Linux sin `bwrap` y `socat`
Su propio worktree	Cada conversación recibe un checkout con copia en escritura. El checkout original se incorpora a la ejecución como ruta de denegación de escritura, y es el entorno aislado quien lo aplica
Credenciales del bróker	El bróker de credenciales emite un entorno por ejecución y lo revoca al desmontar. Su token de GitHub puede leer pero no hacer push: un push pasa por Control Center, que primero pregunta a la regla de push
Barandillas de acciones	Cada herramienta mutadora declara sus clases de efecto y la barandilla las resuelve antes de que se ejecute la llamada. Un `prompt` sin ningún aprobador conectado se deniega
Saneamiento del entorno	ACP y la herramienta `bash` del arnés reciben un entorno filtrado. Claude Code a través de `NoSandboxAdapter` hereda el entorno del host
La superficie de herramientas del modo	Un modo de solo lectura elimina por completo las herramientas que mutan el worktree y fija el propio verbo de salida del modo para que este siga pudiendo entregar

Tres cosas son más débiles de lo que parecen:

Solo el arnés integrado aplica la puerta de herramientas, los contratos de finalización y las reglas estructurales del modo. El adaptador de Claude Code no. En particular, Claude Code se lanza con --dangerously-skip-permissions, porque un claude -p no interactivo se quedaría bloqueado para siempre en su propio prompt; así que Control Center ni ve ni pone puertas a las propias llamadas de lectura, escritura y edición de Claude, y sus comandos de bash solo los comprueba un hook que lee la línea de comandos. Donde el entorno aislado está activado, es la frontera que los rodea.
Las herramientas de archivos en proceso del arnés (read, write, edit, apply patch, search, find, search_files) se ejecutan dentro del proceso del servidor, así que ningún perfil de entorno aislado las limita. Solo la herramienta bash pasa por el ejecutor de comandos aislado. Esas herramientas están acotadas por su propio confinamiento de rutas y por las barandillas de acciones.
En un host sin backend, la primera fila no se aplica en absoluto. ACP y la herramienta bash del arnés recurren al saneamiento del entorno más la política de comandos; Claude Code hereda el entorno del host a través de NoSandboxAdapter. El servidor lo indica en su registro de arranque. Consulta el tuyo más abajo.

Decidir qué puede enviar un agente

No hay ningún interruptor por agente para git push, GitHub, tickets o la red. Cada uno es una regla de acción:

Regla	Valor predeterminado	Qué cubre
Enviar a un remoto	Preguntar primero	Cada `git push` a GitHub, sea cual sea el adaptador
Abrir una pull request	Preguntar primero	`gh pr create` y las herramientas de pull requests
Publicar una revisión o fusionar	Preguntar primero	`gh pr merge`, `gh pr review`, `gh pr comment`, `gh pr close`
Escribir en un rastreador externo	Preguntar primero	Escrituras de tickets con las herramientas de Control Center y `gh issue`
Acceder a la red	Permitir	Si el entorno aislado tiene red, y las herramientas web del arnés

Ve a Ajustes → Espacio de trabajo → Permisos de agentes
Elige el ámbito —Espacio de trabajo, Agente o Espacio— y, en la fila de la regla, elige Permitir, Preguntar primero o Denegar

Las reglas de push limitadas a ramas, como una que deniega los push a main, también se aplican: consulta Barandillas.

Punto de control: pide al agente que haga push de una rama. Con Preguntar primero recibes una aprobación que indica el repositorio y las refs; con Denegar, git muestra ! [remote rejected] <ref> (Control Center policy: …).

Cómo llega cada regla a la ejecución:

El push se aplica por lo que tiene la ejecución. Su token de GitHub es un token de instalación de GitHub App de solo lectura, que puede leer contenido y trabajar con pull requests. Su configuración de git envía cada push a GitHub a una pasarela de loopback en cc_server, que pregunta a la regla y solo entonces reenvía el push con un token de escritura que el agente nunca ve. La pasarela solo reenvía al repositorio propio del worktree o a un repositorio de GitHub vinculado al espacio de trabajo. Esto vale para todos los adaptadores.
Las pull requests y las issues desde un shell se reconocen por la línea de comandos, en la herramienta bash del arnés y, mediante un hook, en la herramienta Bash de Claude Code. Un agente que oculte el comando (un script, eval, una llamada directa a la API) se salta esta comprobación, pero no la pasarela de push.
Las claves de tickets nunca se colocan en el entorno aislado. Los agentes escriben tickets con las herramientas MCP de Control Center, que preguntan a la regla.
La red se resuelve una sola vez, cuando arranca la ejecución. Denegar desactiva la red del entorno aislado; Permitir y Preguntar primero la dejan activada, y con Preguntar primero las herramientas web_fetch y web_search del arnés siguen preguntando en cada llamada. Mientras la red está activada, GitHub siempre está en la lista de permitidos de salida.

Comprobar si tus ejecuciones de agente están en un entorno aislado

Lo deciden dos cosas, ambas en el servidor: si el host ofrece un backend y si --sandbox está activado. Compruébalas en ese orden.

Ve a Ajustes → Servidor → Diagnóstico y privacidad
Consulta la tarjeta Aislamiento. El dato Host es la máquina en la que se ejecuta cc_server, no la que estás mirando. El campo Backend muestra Native sandbox (Seatbelt en macOS, bubblewrap en Linux y WSL2) o No isolation. El dato En vigor es la preferencia de este dispositivo, no el envoltorio que usa realmente el servidor.
Consulta el registro de arranque del servidor. Imprime exactamente una de estas tres líneas:
- agent sandbox ON más la nota del backend: las ejecuciones van envueltas
- no OS-native agent sandbox on this host más una indicación de instalación cuando existe: las ejecuciones no van envueltas
- agent sandbox DISABLED by --sandbox off: una exclusión deliberada

GET /healthz no informa del estado del entorno aislado, así que el registro de arranque es la comprobación.

Para desactivar el entorno aislado a propósito —un host en el que el perfil se comporta mal es la razón de que exista esta opción—, inicia el servidor con --sandbox off o define CC_SERVER_SANDBOX=off. El valor predeterminado es on, y on significa «usar un backend si el host tiene uno», nunca «exigir uno».

Hay dos situaciones que nunca reciben un envoltorio de entorno aislado nativo. En Windows, la sonda nativa siempre informa de que no está disponible y no hay nada que instalar: el despacho de agentes usa none. El backend microvm es aparte (terminales interactivas y rigs) y está sujeto a sonda según su propio runtime. En Linux y WSL2, tanto bwrap como socat deben estar en el PATH; sin ellos, la sonda informa de que no está disponible y nombra los paquetes que faltan.

En Linux/WSL2 con bubblewrap instalado, los globs de archivos de secretos de la política estándar no se pueden aplicar a los archivos que un agente cree después. Esa ejecución nativa ahora falla en lugar de ignorar las reglas en silencio. Por tanto, una sonda de arranque positiva no garantiza que un despacho en Linux pueda iniciarse. --sandbox off es una exclusión deliberada sin confinamiento, no una frontera de seguridad sustitutiva.

Saber qué prohíbe ya un modo

El modo se guarda por espacio y alimenta al resolutor de barandillas como la capa de preajuste del modo. Tres de los cuatro modos son de solo lectura, y un modo de solo lectura rechaza once clases de efecto de plano:

Modo	Worktree	Rechazadas por el preajuste
Agent (`chat`)	Se puede escribir	Ninguna: se aplican los valores predeterminados integrados
Plan	Solo lectura	Eliminar un archivo, escribir fuera del worktree, hacer commit, hacer push, abrir una PR, publicar o fusionar, escribir en un proveedor externo de tickets, instalar un paquete, lanzar un proceso, cambiar la estructura del espacio de trabajo, arrancar o controlar un recinto
Review	Solo lectura	Las mismas once. No lo puede seleccionar el usuario: el compositor solo ofrece Agent, Plan y Orchestrate
Orchestrate	Solo lectura	Las mismas once

Los modos de solo lectura no rechazan a propósito el acceso a la red ni a los secretos: la investigación es justo su objetivo.

Exigir aprobación antes de que se ejecute una acción

La aprobación es una decisión de las barandillas, no un ajuste del entorno aislado.

Ve a Ajustes → Espacio de trabajo → Permisos de agentes
Define la clase de acción como Preguntar primero en el ámbito de espacio de trabajo, agente o espacio

Una decisión Preguntar primero interrumpe la ejecución y te pregunta. Si no hay ningún aprobador conectado, falla en cerrado y la acción se deniega. Consulta Configurar barandillas para ver el orden de resolución completo.

Solución de problemas

Un agente no puede hacer push y yo nunca lo denegué

Lee lo que ha mostrado git. Control Center policy: … significa que una regla denegó el push o que un Preguntar primero quedó sin respuesta. … is not linked to this workspace significa que el push apunta a un repositorio que no es el del worktree ni está vinculado al espacio de trabajo. Control Center has no GitHub credential that can push … significa que la GitHub App no está instalada en ese repositorio y que ninguna credencial alternativa podía hacer push: instala la App en él o conecta GitHub.

La tarjeta Aislamiento informa de que no hay entorno aislado nativo

Entonces las ejecuciones de agente en ese host no van envueltas por Seatbelt ni bubblewrap, y las fronteras restantes son las que tienes. En Linux y WSL2, instala las dos herramientas que faltan —sudo apt-get install bubblewrap socat— y reinicia el servidor; el registro de arranque debería indicar entonces que el entorno aislado está activado. En Windows no hay ningún backend nativo que instalar, así que ajusta mejor las barandillas: consulta Configurar barandillas.

Un agente llegó a un archivo fuera de su worktree

La herramienta con la que llegó decide si esto es lo esperado.

Las herramientas de archivos en proceso del arnés (read, write, edit, apply patch, search, find, search_files) se ejecutan en el proceso del servidor, así que no se les aplica ningún perfil de entorno aislado: su límite es su propio confinamiento de rutas más las barandillas. Un comando bash o la CLI de Claude Code sí van envueltos donde existe un backend, y tus checkouts registrados tienen la escritura denegada dentro de ese envoltorio en todos los modos, incluidas sus grafías resueltas por enlaces simbólicos (en macOS, una ruta a la que se llega a través de /tmp o /var/folders se resuelve bajo /private, y ahora se deniegan ambas grafías). En un host sin backend, nada de eso se aplica. En cualquier caso, las barandillas pueden rechazar Escribir fuera del árbol de trabajo de plano.