Cómo ejecutar Claude Code de forma segura

Qué significa ejecutar Claude Code de forma segura en un servidor

Para ejecutar Claude Code de forma segura en un servidor, mantenga activados sus avisos de permisos, ejecútelo como un usuario sin privilegios dedicado y proporcione a las ejecuciones no supervisadas un límite real en lugar de confianza: el sandbox integrado, un contenedor o un VPS desechable que no contenga nada importante. El flag --dangerously-skip-permissions elimina el paso de aprobación entre el modelo y su shell. Ese intercambio puede ser razonable para trabajo no supervisado, pero solo dentro de un límite que restrinja el alcance de un comando malicioso. Esta guía explica qué cambia realmente el flag y cómo construir ese límite mediante niveles de aislamiento progresivo.

Qué puede hacer Claude Code en su máquina

Claude Code es un agente de programación que se ejecuta en su terminal. Lee archivos, escribe archivos y ejecuta comandos de shell como el usuario que lo inició. Ese es el valor principal de la herramienta: puede clonar un repositorio, editar código, ejecutar tests, leer el error y corregir el código en un bucle, sin que usted tenga que escribir cada comando. Si aún no lo ha configurado en un servidor, ejecutar Claude Code en un VPS con tmux cubre la instalación y el manejo de la sesión. Esta página cubre el poder que usted le otorga una vez instalado.

El riesgo es la misma frase leída dos veces. Un proceso que ejecuta comandos de shell como su usuario puede hacer cualquier cosa que su usuario pueda hacer. Puede leer ~/.ssh/id_ed25519, ~/.aws/credentials y cada archivo .env que su usuario pueda abrir. Puede ejecutar curl y enviar datos a cualquier host al que el servidor tenga acceso. Puede ejecutar git push --force. El agente no tiene motivos propios. El peligro es que una tarea falle, o que el texto que leyó mientras trabajaba contuviera instrucciones escritas por alguien más: una página web que descargó o un comentario en un issue que se le pidió corregir. Ese segundo caso se llama prompt injection, y es la razón por la que "el modelo suele ser sensato" no es un plan de seguridad. Usted debe planificar para la ejecución fallida, no para la promedio.

El sistema de permisos en palabras sencillas

Por defecto, Claude Code pregunta antes de actuar. La lectura de archivos dentro del proyecto ocurre de forma silenciosa, pero editar un archivo o ejecutar un comando de shell le muestra primero la edición o el comando exacto y espera un "sí". Puede aprobar una acción o aprobar ese tipo de acción para el resto de la sesión. Esas aprobaciones tienen alcance de sesión: si cierra la CLI, la siguiente sesión comenzará con cautela nuevamente. Para las reglas que desee mantener, el archivo de configuración guarda listas persistentes de permitir, preguntar y denegar. Por ejemplo: permitir git status, preguntar en git push, denegar lecturas de .env. Las reglas de denegación siempre tienen prioridad.

Este diseño asume que un humano está vigilando la terminal, lo cual es cierto en una laptop. En un servidor, el punto suele ser que nadie está vigilando. Usted inicia una tarea larga dentro de tmux y se va a dormir, y un agente que se detiene a hacer una pregunta a las 2 a.m. no progresa hasta la mañana. La pausa cuesta tanto tiempo como dinero, porque una sesión de Claude Code inactiva pierde su caché de prompt caliente y el siguiente turno debe pagar para reconstruirlo. Esa es la razón honesta por la que la gente recurre al flag de omitir en servidores, y el problema que resuelve es real. El resto de esta guía trata sobre cómo resolverlo sin renunciar a todas las protecciones.

Qué cambia --dangerously-skip-permissions

claude --dangerously-skip-permissions desactiva el paso de aprobación. Las ediciones ocurren sin avisos. Los comandos de shell se ejecutan sin avisos. Las comprobaciones de rutas protegidas que normalmente custodian ubicaciones sensibles también se omiten. Sus reglas de denegación explícitas siguen aplicándose, y algunas acciones extremas seguirán deteniéndose para preguntar, pero el resumen de funcionamiento es simple: lo que el modelo decida ejecutar, se ejecuta.

Dos hechos sobre el flag son importantes en un servidor. Primero, está bloqueado cuando Claude Code se ejecuta como root o bajo sudo en Linux y macOS, porque root sin avisos puede cambiar cualquier archivo o servicio en la máquina. El agente necesita su propia cuenta sin privilegios de todos modos, y el flag refuerza eso. Segundo, el flag no cambia el comportamiento del modelo de ninguna manera. Elimina al humano del bucle y no cambia nada más, por lo que cada error que un aviso habría detectado ahora se ejecuta.

Así que este es el cálculo honesto. Si omite los permisos, la pregunta de seguridad cambia de "¿hará algo malo el agente?" a "¿cuánto daño puede causar una mala acción?". Usted deja de intentar controlar cada decisión y comienza a controlar el radio de explosión. El confinamiento es la respuesta, y se presenta en niveles.

El sandbox integrado de Claude Code

Antes de los niveles, sepa que Claude Code ahora incluye un sandbox a nivel de OS para los comandos que ejecuta, y esto elimina la mayoría de las razones por las que la gente recurría al flag de omitir. En Linux utiliza bubblewrap para el aislamiento del sistema de archivos, además de socat para enrutar el tráfico de red a través de un proxy. Dentro del sandbox, un comando solo puede escribir en el directorio del proyecto y en un directorio temporal de sesión, y solo puede acceder a la red a través de un proxy que verifica cada dominio contra una lista de permitidos. La primera vez que un comando requiere un nuevo dominio, Claude Code se lo pregunta.

Actívelo con el comando /sandbox dentro de una sesión. En Ubuntu y Debian, instale primero los dos paquetes que necesita:

sudo apt install bubblewrap socat

En Ubuntu 24.04 y versiones posteriores, la política predeterminada de AppArmor impide que bubblewrap cree los namespaces de usuario que necesita. El panel del sandbox le indicará cuando falte algo, y la documentación de sandboxing de Claude Code contiene el perfil corto de AppArmor que lo soluciona.

El sandbox tiene un modo de permitir automáticamente: los comandos en el sandbox se ejecutan sin ningún aviso, porque el límite aplicado ahora realiza el trabajo que antes hacía el aviso. Los comandos que no pueden ejecutarse dentro del sandbox vuelven al flujo de permisos normal, por lo que las acciones genuinamente inusuales seguirán preguntando. Para la mayoría de los flujos de trabajo en servidores, este es el reemplazo correcto para el flag de omitir, porque obtiene muchas menos preguntas con un límite aplicado por el OS en lugar de ninguna.

Sea honesto sobre sus límites. Por defecto, un comando en el sandbox aún puede leer la mayor parte del sistema de archivos, incluidos archivos de credenciales, a menos que deniegue esas rutas; la configuración sandbox.credentials existe precisamente para eso. El proxy de red verifica nombres de dominio y no inspecciona el tráfico en sí, por lo que un permiso amplio como github.com sigue dejando espacio para extraer datos. Docker no funciona dentro de él. El sandbox eleva mucho el nivel base. No es un límite de aislamiento completo, razón por la cual los niveles siguientes siguen siendo importantes.

La escalera de confinamiento

Tres niveles, en orden creciente de aislamiento. Elija el más bajo que coincida con lo que más reside en la máquina.

Nivel 1: un usuario sin privilegios dedicado. El agente obtiene su propia cuenta, su propio directorio home, su propio directorio de proyecto y ningún sudo:

sudo adduser --disabled-password --gecos "" agent

El límite de la cuenta mantiene al agente fuera de sus archivos: sus llaves SSH y cualquier otro proyecto en la máquina. También hace que el flag de omitir sea utilizable, ya que el flag se niega a ejecutarse como root. Este es el mismo principio que ejecutar cada servicio como un usuario sin privilegios, aplicado a un agente. Lo que el nivel 1 no limita: la red y cualquier cosa en la máquina que sea legible por todos los usuarios.

Nivel 2: un contenedor. Anthropic publica un devcontainer de referencia que ejecuta Claude Code como un usuario no-root, con reglas de firewall que limitan a qué hosts puede acceder el agente; un contenedor que usted construya mismo hace el mismo trabajo. El sistema de archivos se reduce a los volúmenes que monte, y la salida de red se reduce a lo que permitan las reglas del contenedor. Este es el nivel medio correcto cuando el servidor aloja otros servicios importantes. Su límite es que los contenedores comparten el kernel del host, y un montaje descuidado anula el límite; entregue al contenedor /var/run/docker.sock y podrá alcanzar todo el host.

Nivel 3: un VPS dedicado. El nivel más fuerte es el más contundente: entregue al agente una máquina completa que no contenga nada importante para usted. Un VPS pequeño cuesta unos pocos dólares al mes. Configúrelo con el manual de los primeros diez minutos en un nuevo VPS, cree una instantánea del estado limpio y deje trabajar al agente. Nada más vive allí. Sin llaves SSH personales, solo una deploy key limitada a un único repositorio. Sin credenciales de la nube, sin datos de producción. Cuando una ejecución falle, o cuando simplemente quiera un lienzo limpio, restaure la instantánea o destruya y reconstruya la máquina en minutos. El radio de explosión es el costo del alquiler. Este es el entorno donde --dangerously-skip-permissions deja de ser aterrador, porque el peor resultado realista es un servidor reconstruido y un token revocado.

Los niveles se acumulan. Un agente en sandbox, ejecutándose como un usuario sin privilegios, en un VPS desechable, no cuesta casi nada extra y hace que las historias de fallos sean aburridas. Lo aburrido es el objetivo.

Proteja las credenciales

La regla que compensa todo lo demás: el usuario del agente no debe poder leer secretos que pertenezcan a cualquier otra cosa.

Entregue la API key al agente y a nada más. Colóquela en un archivo propiedad del usuario del agente con modo 600, y cárguela cuando inicie una shell:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

Luego cierre la otra dirección. En Debian y Ubuntu, los directorios home suelen crearse como legibles para todos los usuarios de la máquina, así que restrinja el suyo: chmod 750 /home/youruser. Verifique con ls -ld /home/* y corrija cualquier cosa que la cuenta del agente pueda listar.

Limite el alcance de cada token. Un token de GitHub de grano fino limitado a un repositorio, o una deploy key por repositorio, significa que una credencial filtrada pierde un proyecto y no toda su cuenta. Si usa el sandbox, añada su configuración de credenciales para que ~/.ssh y ~/.aws sean denegados incluso para lecturas. Y mantenga las credenciales de producción fuera de la máquina por completo, porque un agente no puede filtrar un secreto que nunca estuvo allí.

Git es la red de seguridad

Cada cambio que el agente realice debe ser revisable y revertible, y git le ofrece ambos de forma gratuita si el agente trabaja en una rama:

git switch -c agent/refactor-auth

Revise la ejecución después con git diff main...agent/refactor-auth, combine lo que sea bueno y elimine la rama si la ejecución no llevó a nada. Proteja la rama principal en el lado del forge, para que el token del agente no pueda hacer push a ella y no pueda hacer force-push en ningún lugar. El historial de commits funciona también como un registro de auditoría de lo que sucedió mientras usted dormía, lo cual vale más que cualquier cantidad de historial de terminal.

La red es parte del radio de explosión

Un agente puede ejecutar curl. Esa frase es todo el problema de salida: cualquier cosa que el agente pueda leer, también puede enviarla a algún lugar, y un agente con prompt injection podría hacerlo. Un usuario sin privilegios simple no limita esto en absoluto, porque cualquier usuario puede alcanzar cualquier cosa que el servidor pueda alcanzar. El sandbox lo limita por dominio a través de su proxy. Un contenedor puede limitarlo con sus propias reglas de firewall. Un VPS dedicado limita lo que hay para filtrar en primer lugar, que es la respuesta más robusta de las tres.

No intente resolver la salida solo con ufw. ufw permite todo el tráfico saliente por defecto, y escribir reglas de salida que aún permitan apt, npm, git y la API de Claude es un trabajo tedioso que falla silenciosamente. Elija el límite a nivel de sandbox, contenedor o máquina en su lugar, donde una lista de dominios permitidos o una máquina pura hacen el mismo trabajo de forma limpia.

Si está construyendo su propio agente contra la API en lugar de ejecutar Claude Code, el mismo pensamiento se aplica sin cambios. Construir un agente de IA con Claude en un VPS cubre ese camino, y su agente merece el mismo usuario dedicado, los mismos tokens limitados y la misma máquina desechable.

Refuerce la máquina primero

Cualquiera que sea el nivel que elija, la máquina misma aún necesita lo básico antes de que el agente se mude: solo llaves SSH, sin login de root, un firewall de denegación por defecto, actualizaciones de seguridad automáticas. Genere su lista de verificación aquí y trabaje sobre ella una sola vez:

FAQ

¿Es seguro usar --dangerously-skip-permissions en un servidor?

No por sí solo. El flag elimina todos los avisos de aprobación, por lo que el primer comando malicioso se ejecuta en el momento en que el modelo lo produce. Se convierte en un intercambio defendible cuando el radio de explosión está contenido: un usuario sin privilegios dedicado como mínimo, y para trabajo genuinamente no supervisado, un contenedor o un VPS desechable que contenga un solo proyecto y un solo token limitado. Nunca lo use en una máquina que contenga credenciales de producción o datos que no pueda perder.

¿Tiene Claude Code un sandbox?

Sí. Claude Code incluye un sandbox integrado para comandos de shell, que se abre con el comando /sandbox. Utiliza bubblewrap en Linux y Seatbelt en macOS, limita las escrituras al directorio del proyecto y enruta el acceso a la red a través de un proxy que solo permite dominios aprobados. Su modo de permitir automáticamente ejecuta comandos en el sandbox sin avisos, por lo que reduce las interrupciones de la misma manera que el flag de omitir, manteniendo un límite aplicado por el OS. No es un límite de aislamiento completo, así que combínelo con un usuario dedicado o una máquina dedicada para ejecuciones no supervisadas.

¿Por qué el flag de omitir se niega a ejecutarse como root?

Porque root, sin avisos de permisos, puede modificar cualquier archivo y cualquier servicio del sistema; Claude Code bloquea --dangerously-skip-permissions cuando se ejecuta como root o bajo sudo en Linux y macOS. La solución no es luchar contra la comprobación. Cree un usuario sin privilegios para el agente y ejecútelo allí; ese límite de cuenta es la primera y más barata capa de confinamiento.

¿Puede Claude Code leer mis llaves SSH y archivos .env?

Puede leer cualquier cosa que el usuario bajo el cual se ejecuta pueda leer, e incluso la política predeterminada del sandbox permite lecturas de rutas de credenciales hasta que usted las deniegue. Por tanto, ejecute el agente como su propio usuario, mantenga su propio directorio home en modo 750 o más restrictivo, deniegue las rutas de credenciales en la configuración del sandbox y mantenga los secretos de producción fuera de la máquina por completo. Un secreto que la máquina nunca tuvo no puede ser leído ni filtrado.

¿Cuál es la forma más segura de ejecutar Claude Code sin supervisión?

Un VPS dedicado económico usado solo para el trabajo del agente: reforzado en diez minutos, con una instantánea limpia, ejecutando Claude Code bajo un usuario sin privilegios con el sandbox activado, un archivo modo-600 que contenga la API key, una deploy key por repositorio y todo el trabajo en ramas que usted revise antes de combinar. Si una ejecución falla, revoca un token y restaura la instantánea, y nada más de su propiedad se verá afectado.