Claude Code ya limita el acceso de red a cada comando

Una instalación de dependencias ya no tiene por qué ampliar el perímetro de red durante el resto de un trabajo de Claude Code. El 14 de septiembre de 2026, Claude Code 2.1.271 incorporó el acceso de red por comando al modo automático dentro del sandbox. Así, el host del registro autorizado para instalar vuelve a cerrarse en cuanto termina ese comando.

Qué cambió realmente en Claude Code

Aquí intervienen dos capas de seguridad distintas de Claude Code. El cambio solo se entiende al separarlas.

El modo automático decide si una llamada de herramienta puede ejecutarse. Un clasificador independiente contrasta la acción con la solicitud. La guía anterior sobre el modo automático de Claude Code explica ese modelo general de permisos.

El sandbox decide a qué puede acceder un comando de shell mientras se ejecuta. Limita la escritura de archivos y encamina el tráfico de red a través de un proxy que comprueba el host de destino.

La versión 2.1.271 estrecha la conexión entre ambas capas. En el modo automático con sandbox, una llamada de Bash, PowerShell o Monitor ahora puede incluir una lista allowed_domains. Claude Code evalúa a la vez el comando y los hosts que necesita. Esos hosts se abren solo para ese comando y el sandbox rechaza los demás. La nota de la versión define ese alcance con claridad.

Ese campo en snake_case no equivale a sandbox.network.allowedDomains en settings.json.

Antes de esta versión, aprobar un host nuevo en el sandbox podía generar un permiso más amplio. Una aprobación manual dura el resto de la sesión actual; si se guarda, puede mantenerse en sesiones posteriores. El modo automático también puede almacenar en caché su decisión sobre un host y un puerto. El campo nuevo cambia el alcance durante la ejecución, incluso cuando se reutiliza el veredicto de un clasificador: la apertura de red pertenece al comando actual.

El cambio solo afecta a la combinación citada en la versión: modo automático, sandbox y Bash, PowerShell o Monitor. Las sesiones manuales, los comandos fuera del sandbox, las herramientas integradas para archivos y los trabajos que nunca usan la red no adquieren este límite.

La cuenta importante es el alcance del permiso, no un plan más barato

El precio de las licencias de Claude Code no cambió. Anthropic no anunció una tarifa aparte, un SKU nuevo ni resultados de rendimiento para los dominios limitados por comando.

La ecuación útil mide el tamaño de la autorización que hay que justificar:

standing grant = approved host × every later command that can reuse it

command-scoped grant = approved host × the reviewed command

Pensemos en una instalación de dependencias que necesita registry.npmjs.org. Antes, la decisión operativa solía ser incómoda: detener un trabajo desatendido para resolver un permiso de red o autorizar previamente el registro y aceptar que todos los comandos posteriores dentro del sandbox pudieran acceder a él. Ahora el modo automático puede aprobar ese host junto con la instalación y cerrarlo antes de continuar con la compilación, las pruebas, el empaquetado y la revisión.

Eso modifica dos partidas operativas aunque la factura de la suscripción siga igual. Los equipos de plataforma tienen menos excepciones permanentes que diseñar y retirar. Quienes revisan la seguridad pueden evaluar un par formado por un comando y un host, en vez de asumir que el host queda disponible durante todo el trabajo restante.

El proceso de revisión sigue consumiendo cómputo. En las cuentas Enterprise y de proveedores con cobro por uso mencionadas en la documentación de Anthropic sobre modos de permisos, las comprobaciones del clasificador cuentan para el consumo de tokens y añaden un viaje de ida y vuelta. La versión no aporta ningún benchmark de tiempo y para este artículo tampoco se hizo una prueba cronometrada, así que no sería honesto prometer segundos ahorrados.

Quién puede aprovecharlo desde mañana

Quien dirige una startup y ejecuta una compilación larga

Quien dirige una startup puede dejar que Claude Code restaure las versiones de los paquetes fijadas en un repositorio SaaS y después continúe con las pruebas y la revisión de código, sin mantener abierto el registro público para esos pasos posteriores. El trabajo sigue avanzando, pero una descarga necesaria no se convierte en una salida de red permanente durante toda la sesión.

El responsable técnico de una agencia que alterna entre repositorios

Una agencia puede vincular el host de paquetes de un cliente exclusivamente a la instalación que lo necesita, en lugar de guardar otra excepción a nivel de proyecto. Así se reduce el trabajo de retirar permisos y resulta más difícil que un comando de la fase siguiente envíe código del cliente a un host que solo se abrió para gestionar dependencias.

Un responsable de plataforma o seguridad que supervisa agentes desatendidos

Un equipo de plataforma puede mantener las reglas de bloqueo de toda la organización y los controles administrados de dominios, mientras los comandos rutinarios solicitan un acceso más estrecho dentro de esa política. El registro de revisión se explica con mayor facilidad: este comando necesitó este host para esta acción. No demuestra que el host fuera seguro para todo lo que el agente hizo después.

Un ingeniero de compilación que separa instalación y pruebas

Un ingeniero de compilación puede convertir la restauración de paquetes en una fase con red y la suite de pruebas en otra sin conexión. Si una prueba comprometida o un script inesperado intenta llamar al registro después de terminar la instalación, no hereda la apertura del comando anterior, salvo que otra regla permanente ya permita ese host.

Cómo instalar dependencias npm con acceso limitado

La forma más clara de entender el cambio es usar un repositorio que incluya un package-lock.json en el control de versiones y cuyas dependencias se resuelvan mediante un único registro conocido. npm documenta npm ci para instalaciones automatizadas y limpias: exige un lockfile, falla si este no coincide con el manifiesto, elimina cualquier node_modules existente y no modifica ni el manifiesto ni el lockfile. La opción --ignore-scripts impide que se ejecuten los scripts del ciclo de vida de los paquetes durante la instalación. npm documenta todos estos comportamientos.

1. 1

   Comprobar la versión de Claude Code

   Ejecuta la comprobación que indica el changelog:

   claude --version

   Usa la versión 2.1.271 o una compilación posterior que incluya la función.

2. 2

   Iniciar el modo automático en un sandbox de cierre seguro

   Para una sola sesión, combina el modo automático con un sandbox que deba arrancar correctamente y que no pueda reintentar fuera de sus límites un comando bloqueado:

   claude --permission-mode auto --settings '{"sandbox":{"enabled":true,"failIfUnavailable":true,"allowUnsandboxedCommands":false}}'

   Aquí se utilizan los controles documentados --permission-mode, --settings, failIfUnavailable y allowUnsandboxedCommands. En macOS, el sandbox viene integrado. Linux y WSL2 necesitan bubblewrap y socat; Windows nativo no es compatible con el sandbox integrado. La guía del sandbox detalla la configuración y los límites de cada plataforma.

3. 3

   Definir una tarea precisa para la instalación

   Envía esta instrucción y sustituye el host del registro si el lockfile utiliza uno privado:

   Instala exactamente las dependencias de package-lock.json con npm ci --ignore-scripts. Este comando solo puede acceder a registry.npmjs.org. No guardes ese host en la configuración del proyecto ni del usuario. Cuando termine la instalación, ejecuta la suite de pruebas como un comando independiente y sin acceso de red. Detente si la instalación necesita cualquier otro host.

   No se escribe manualmente el campo allowed_domains. Claude Code construye la llamada a la herramienta de shell y el modo automático revisa el host solicitado junto con esa llamada.

4. 4

   Verificar que el siguiente paso empieza sin acceso

   Abre /sandbox, revisa la pestaña Config de la configuración resuelta y comprueba que registry.npmjs.org no figure ya en un allowedDomains permanente ni en una regla WebFetch guardada. Después, deja que se ejecute el comando de pruebas por separado. Cualquier intento de red de ese comando posterior debe requerir su propio conjunto de dominios revisados o ser rechazado por la política vigente.

El detalle que suele pasarse por alto es el lockfile. Un archivo de bloqueo puede apuntar a un registro privado, un host de Git o la URL directa de un tarball. Indicar únicamente registry.npmjs.org no hace que esas dependencias aparezcan allí. Revisa los hosts resueltos reales, mantén la lista exacta y deja que el comando se detenga si el lockfile solicita algo inesperado.

Lo que el acceso por comando no resuelve

Limitar el acceso de red por comando reduce el intervalo durante el cual se puede llegar a un host. No demuestra que el host sea confiable, no inspecciona todas las solicitudes cifradas ni convierte el código descargado en código seguro.

El proxy integrado de Anthropic filtra por nombre de host y, de forma predeterminada, no inspecciona el contenido TLS. Durante el comando autorizado, un proceso puede acceder a cualquier ruta permitida de ese host. Los procesos secundarios iniciados por el comando comparten los límites del sandbox. Por eso npm ci --ignore-scripts sirve como ejemplo didáctico: elimina los scripts del ciclo de vida de los paquetes en la instalación, pero no audita los paquetes descargados.

La política administrada sigue estando por encima de esta función. strictAllowlist puede bloquear todo lo que quede fuera de la lista configurada y allowManagedDomainsOnly puede restringir los hosts permitidos a los ajustes administrados. Las reglas de bloqueo explícitas siguen prevaleciendo. Los dominios por comando no atraviesan esos controles.

El reintento fuera del sandbox es otro caso límite real. Claude Code suele ofrecer una vía de escape para los comandos que el sandbox no puede ejecutar. Establecer allowUnsandboxedCommands en false es importante porque evita que una instalación fallida cambie silenciosamente la pregunta «¿a qué host puede acceder este comando?» por «¿puede ejecutarse este comando fuera del sandbox?».

Qué conviene hacer el lunes

Conviene actuar esta semana si Claude Code se ejecuta en modo automático para actualizar dependencias, realizar mantenimiento nocturno o gestionar compilaciones desatendidas, y los registros de paquetes aún figuran en una lista amplia de permisos del sandbox. Esta función permite comprobar si esas entradas permanentes ya se pueden retirar.

Conviene esperar si la organización aplica una política de red administrada que autoriza deliberadamente el registro para todos los comandos, o si un contenedor externo o el ejecutor de CI ya impone una regla de salida más estricta por proceso. El campo nuevo aún puede sumar defensa en profundidad, pero no sustituye el límite que ya está operativo.

El cambio no afecta a quienes no usan el modo automático con sandbox, ni a los trabajos que nunca llaman a Bash, PowerShell o Monitor a través de la red.

La acción para el lunes es pequeña: confirma que Claude Code sea 2.1.271 o posterior, elige una instalación de dependencias con lockfile, iníciala en modo automático con un sandbox de cierre seguro, indica solo el host del registro esperado y demuestra que el siguiente comando de pruebas no puede reutilizar esa ruta de red. Retira una excepción permanente para el registro únicamente después de que esa comprobación pase en el entorno propio.

Si quieres saber cómo afecta al flujo de trabajo el próximo cambio de plataforma, suscríbete al newsletter.