Cómo ejecutar Claude Code de forma segura en un servidor

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

Para ejecutar Claude Code de forma segura en un servidor, mantenga activadas las solicitudes de permisos, ejecútelo con un usuario dedicado sin privilegios y proporcione a las ejecuciones desatendidas un límite de seguridad real en lugar de confiar en ellas: el sandbox integrado, un contenedor o un VPS desechable que no contenga nada importante. El indicador --dangerously-skip-permissions elimina el paso de aprobación entre el modelo y el shell. Esta compensación puede ser razonable para tareas desatendidas, pero sólo dentro de un límite que restrinja el alcance de un comando incorrecto. Esta guía explica qué cambia realmente el indicador y cómo establecer ese límite mediante niveles de aislamiento progresivo.

Qué puede hacer Claude Code en su servidor

Claude Code es un agente de programación que se ejecuta en el terminal. Lee archivos, escribe archivos y ejecuta comandos de shell con el usuario que lo inició. Ese es todo el valor de la herramienta: puede clonar un repositorio, editar el código, ejecutar las pruebas, leer el error y corregir el código en un ciclo, sin que tenga que escribir cada comando. Si todavía no lo ha configurado en un servidor, ejecutar Claude Code en un VPS con tmux explica la instalación y la gestión de sesiones. Esta página explica los privilegios que le concede cuando ya está instalado.

El riesgo se entiende mejor si se repite la primera frase. Un proceso que ejecuta comandos de shell con su usuario puede hacer todo lo que puede hacer ese usuario. Puede leer ~/.ssh/id_ed25519, ~/.aws/credentials y todos los archivos .env que su usuario pueda abrir. Puede ejecutar curl y enviar datos a cualquier host al que el servidor pueda acceder. Puede ejecutar git push --force. El agente no tiene objetivos propios. El peligro es que una tarea falle o que el texto que lea durante el trabajo contenga instrucciones escritas por otra persona: una página web que haya descargado o un comentario de una incidencia que se le haya pedido corregir. Este segundo caso se denomina inyección de prompts. Por eso, que «el modelo suele comportarse de forma razonable» no es un plan de seguridad. Las instrucciones también pueden llegar desde un origen más cercano, porque dos sesiones de Claude Code en el mismo servidor pueden enviarse texto, y un mensaje de una sesión hermana es simplemente más texto que el agente receptor lee. Debe planificar el caso de una ejecución incorrecta, no el comportamiento medio.

El sistema de permisos en términos sencillos

De forma predeterminada, Claude Code solicita confirmación antes de actuar. La lectura de archivos dentro del proyecto se realiza sin mostrar avisos, pero al editar un archivo o ejecutar un comando de shell muestra primero la modificación o el comando exactos y espera una confirmación. Puede aprobar una acción o aprobar ese tipo de acción durante el resto de la sesión. Estas aprobaciones se aplican a la sesión actual: si sale de la CLI, la siguiente sesión vuelve a iniciarse con el modo cauteloso. Para las reglas que quiera conservar, el archivo de configuración contiene listas persistentes de acciones permitidas, que requieren confirmación y denegadas. Por ejemplo: permitir git status, solicitar confirmación para git push y denegar las lecturas de .env. Las reglas de denegación siempre tienen prioridad. Esta configuración predeterminada también está cambiando, porque el modo automático pasa a ser el predeterminado el 14 August 2026. Por eso conviene saber qué permite realmente cada modo de permisos antes de decidir cuál debe ejecutar un servidor que no puede supervisar.

Este diseño presupone que una persona supervisa el terminal, y en un portátil eso suele ser cierto. En un servidor, a menudo no hay nadie supervisándolo. Inicia una tarea larga dentro de tmux y se va a dormir. Si el agente se detiene para hacer una pregunta a las 2 a.m., no avanza hasta la mañana. La pausa cuesta tiempo y dinero, porque una sesión inactiva de Claude Code pierde su caché de prompts activo y el siguiente turno debe reconstruirlo, con el coste correspondiente. Esa es la razón real por la que se usa la opción skip en servidores, y el problema que resuelve es real. El resto de esta guía explica cómo resolverlo sin renunciar a todas las medidas de protección.

Qué cambia --dangerously-skip-permissions

claude --dangerously-skip-permissions desactiva el paso de aprobación. Las ediciones se realizan sin solicitar confirmación. Los comandos de shell se ejecutan sin solicitar confirmación. También se omiten las comprobaciones de rutas protegidas que normalmente controlan las ubicaciones sensibles. Las reglas de denegación explícitas siguen aplicándose y algunas acciones extremas todavía se detienen para solicitar confirmación, pero el resumen práctico es sencillo: se ejecuta todo lo que el modelo decida ejecutar.

En un servidor, hay dos aspectos importantes de esta opción. Primero, se bloquea cuando Claude Code se ejecuta como root o mediante sudo en Linux y macOS, porque root sin solicitudes de confirmación puede modificar cualquier archivo o servicio de la máquina. El agente necesita de todos modos su propia cuenta sin privilegios, y la opción lo exige. Segundo, la opción no cambia el comportamiento del modelo de ninguna manera. Retira al usuario del proceso y no cambia nada más, por lo que cualquier error que una solicitud de confirmación habría detectado ahora se ejecuta.

Este es el análisis real. Si omite los permisos, la pregunta de seguridad cambia de «¿hará el agente algo dañino?» a «¿cuánto daño puede causar una sola acción incorrecta?». Deja de intentar controlar cada decisión y empieza a controlar el alcance del impacto. La contención es la respuesta y tiene varios niveles.

El sandbox integrado de Claude Code

Antes de pasar a los niveles, tenga en cuenta que Claude Code ahora incluye un sandbox a nivel del sistema operativo para los comandos que ejecuta. Esto elimina la mayoría de los motivos por los que antes se usaba la opción skip. En Linux utiliza bubblewrap para aislar el sistema de archivos y socat para dirigir el tráfico de red a través de un proxy. Dentro del sandbox, un comando sólo puede escribir en el directorio del proyecto y en un directorio temporal de la sesión. También sólo puede acceder a la red a través de un proxy que comprueba cada dominio con una lista de permitidos. La primera vez que un comando necesita un dominio nuevo, Claude Code le 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 posteriores, la política AppArmor predeterminada impide que bubblewrap cree los espacios de nombres de usuario que necesita. El panel del sandbox le indica si falta algún componente. La documentación de sandboxing de Claude Code incluye el perfil de AppArmor breve que corrige este problema.

El sandbox tiene un modo de autorización automática. Los comandos que se ejecutan dentro del sandbox no muestran ninguna solicitud de confirmación, porque el límite aplicado por el sistema operativo sustituye la protección que antes proporcionaba la solicitud. Los comandos que no pueden ejecutarse dentro del sandbox vuelven al flujo normal de permisos. Por tanto, las acciones realmente inusuales siguen solicitando confirmación. Para la mayoría de los flujos de trabajo de servidor, esta es la sustitución correcta de la opción skip, porque reduce mucho las preguntas y mantiene un límite aplicado por el sistema operativo.

Sea consciente de sus límites. De forma predeterminada, un comando dentro del sandbox todavía puede leer la mayor parte del sistema de archivos, incluidos los archivos de credenciales, salvo que deniegue esas rutas. La opción sandbox.credentials existe precisamente para eso. El proxy de red comprueba los nombres de dominio, pero no inspecciona el tráfico. Por tanto, una autorización amplia como github.com todavía permite extraer datos. Docker no funciona dentro del sandbox. El sandbox mejora mucho la seguridad mínima. No es un límite de aislamiento completo. Por eso siguen siendo importantes los niveles siguientes.

La escalera de aislamiento

Tres niveles, ordenados de menor a mayor aislamiento. Elija el nivel más bajo que se ajuste a lo que también se ejecuta en el servidor.

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

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

El límite de la cuenta mantiene al agente fuera de sus archivos: sus claves SSH y todos los demás proyectos del equipo. También permite usar el indicador de omisión, porque este se niega a ejecutarse como root. 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 elemento del equipo que sea legible para todos.

Nivel 2: un contenedor. Anthropic publica un devcontainer de referencia que ejecuta Claude Code como usuario no root, con reglas de firewall que limitan los hosts a los que puede llegar el agente. Un contenedor creado por usted cumple la misma función. El sistema de archivos se reduce a los volúmenes que monte, y las conexiones salientes se reducen a lo que permitan las reglas del contenedor. Este es el nivel intermedio adecuado cuando el servidor aloja otros servicios que desea proteger. Su límite es que los contenedores comparten el kernel del host, y un montaje incorrecto elimina la separación; si entrega al contenedor /var/run/docker.sock, podrá acceder a todo el host.

Nivel 3: un VPS dedicado. El nivel más sólido también es el más directo: asigne al agente una máquina completa que no contenga nada que le importe. Un VPS pequeño cuesta unos pocos dólares al mes. Prepárelo con el procedimiento de los primeros diez minutos en un VPS nuevo, cree una instantánea del estado limpio y deje que el agente trabaje. No aloja nada más. No use ninguna clave SSH personal, sólo una clave de despliegue limitada a ese repositorio. No incluya credenciales de la nube ni datos de producción. Si una ejecución sale mal, o si simplemente quiere empezar desde cero, restaure la instantánea o destruya y vuelva a crear el servidor en unos minutos. El radio de impacto se limita al coste del alquiler. En esta configuración, --dangerously-skip-permissions deja de ser preocupante, porque el peor resultado realista es reconstruir el servidor y revocar un token.

Los niveles se pueden combinar. Un agente aislado, que se ejecuta como usuario sin privilegios en un VPS desechable, cuesta casi lo mismo y hace que los fallos sean poco interesantes. Ese es el objetivo.

Proteger las credenciales

La regla que sustenta todo lo demás es la siguiente: el usuario del agente no debe poder leer secretos que pertenezcan a otros servicios.

Proporcione la clave de API al agente y a ningún otro usuario. Guárdela en un archivo propiedad del usuario del agente, con permisos 600, y cárguela cuando se inicie un 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

Después, cierre el acceso en la otra dirección. En Debian y Ubuntu, los directorios personales suelen crearse con permisos de lectura para todos los usuarios del sistema. Restrinja el suyo: chmod 750 /home/youruser. Compruébelo con ls -ld /home/* y corrija cualquier elemento que la cuenta del agente pueda listar.

Limite el alcance de cada token. Un token de GitHub con permisos detallados, limitado a un solo repositorio, o una deploy key independiente por repositorio, hace que una credencial filtrada afecte a un solo proyecto y no a toda la cuenta. Si usa el sandbox, añada su configuración de credenciales para que ~/.ssh y ~/.aws queden denegados incluso para las operaciones de lectura. Mantenga también las credenciales de producción fuera del sistema, porque un agente no puede filtrar un secreto que nunca estuvo allí. Si esos secretos se almacenan en un gestor de contraseñas autohospedado, manténgalo en un sistema distinto del agente y sométalo a una revisión independiente, porque los puntos débiles de Vaultwarden son el token de administración y el archivo de copia de seguridad, no el almacén cifrado en sí.

Git es la red de seguridad

Todos los cambios que realice el agente deben poder revisarse y revertirse. Git ofrece ambas cosas sin coste adicional 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, integre los cambios correctos y elimine la rama si la ejecución no produjo resultados útiles. Es mucho más fácil revisar durante el desayuno una ejecución que modificó tres archivos que otra que reescribió la mitad del módulo. Este es el caso práctico de una habilidad que obliga al agente a aplicar el cambio mínimo que funciona. Proteja la rama principal en el forge para que el token del agente no pueda enviar cambios a ella ni hacer force-push en ningún sitio. El historial de commits también funciona como un registro de auditoría de lo ocurrido mientras dormía. Esto vale más que cualquier cantidad de desplazamiento por la terminal.

La red forma parte del alcance del incidente

Un agente puede ejecutar curl. Esa frase resume todo el problema de las conexiones salientes: todo lo que el agente puede leer también puede enviarlo a algún destino, y un agente afectado por una inyección de instrucciones podría hacerlo. Un usuario sin privilegios no limita este alcance, porque cualquier usuario puede acceder a todo lo que el servidor puede alcanzar. El sandbox lo limita por dominio mediante su proxy. Un contenedor puede limitarlo con sus propias reglas de firewall. Un VPS dedicado limita desde el principio la cantidad de datos que se pueden filtrar, por lo que es la respuesta más sólida de las tres.

No intente resolver las conexiones salientes sólo con ufw. ufw permite todo el tráfico saliente de forma predeterminada, y escribir reglas salientes que sigan permitiendo apt, npm, git y la API de Claude requiere un trabajo complejo que puede fallar sin avisar. Elija el límite en el nivel del sandbox, el contenedor o la máquina. En esos niveles, una lista de dominios permitidos o una máquina independiente cumplen la misma función de forma clara.

Si está creando su propio agente con la API en lugar de ejecutar Claude Code, el mismo criterio se aplica sin cambios. Crear un agente de IA con Claude en un VPS explica ese proceso, y el agente debe usar el mismo usuario dedicado, los mismos tokens con permisos limitados y la misma máquina desechable.

Refuerce primero el servidor

Independientemente del nivel que elija, la propia máquina necesita las medidas básicas antes de instalar el agente: sólo claves SSH, sin inicio de sesión de root, un firewall con denegación predeterminada y actualizaciones de seguridad automáticas. Genere aquí su lista de comprobación y complétela una vez, de principio a fin:

FAQ

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

No por sí solo. El indicador elimina todas las solicitudes de aprobación, por lo que el primer comando peligroso se ejecuta en cuanto el modelo lo genera. Se convierte en una decisión defendible cuando el alcance del daño está contenido: como mínimo, un usuario dedicado sin privilegios; y, para tareas realmente desatendidas, un contenedor o una VPS desechable que contenga un solo proyecto y un único token con permisos limitados. No lo use nunca en una máquina que contenga credenciales de producción o datos que no pueda perder.

¿Claude Code tiene un sandbox?

Sí. Claude Code incluye un sandbox integrado para comandos de shell, que se abre con el comando /sandbox. Usa bubblewrap en Linux y Seatbelt en macOS, limita las escrituras al directorio del proyecto y dirige el acceso de red mediante un proxy que sólo permite dominios aprobados. Su modo de autorización automática ejecuta los comandos dentro del sandbox sin solicitar confirmación. Así reduce las interrupciones igual que el indicador de omisión, pero mantiene un límite impuesto por el sistema operativo. No constituye un límite de aislamiento completo, por lo que debe combinarlo con un usuario dedicado o una máquina dedicada para las ejecuciones desatendidas.

¿Por qué el indicador de omisión se niega a ejecutarse como root?

Porque root sin solicitudes de permiso puede modificar cualquier archivo y cualquier servicio del sistema. Por eso Claude Code bloquea --dangerously-skip-permissions cuando se ejecuta como root o mediante sudo en Linux y macOS. La solución no es intentar eludir la comprobación. Cree un usuario sin privilegios para el agente y ejecútelo con esa cuenta. El límite de la cuenta es la primera capa de contención y la menos costosa.

¿Claude Code puede leer mis claves SSH y mis archivos .env?

Puede leer todo lo que pueda leer el usuario con el que se ejecuta. Incluso la política predeterminada del sandbox permite leer rutas de credenciales hasta que se deniegan de forma explícita. Por tanto, ejecute el agente con su propio usuario, mantenga su directorio personal con permisos 750 o más restrictivos, deniegue las rutas de credenciales en la configuración del sandbox y mantenga completamente fuera de la máquina los secretos de producción. Un secreto que la máquina nunca ha almacenado no se puede leer ni filtrar.

¿Cuál es la forma más segura de ejecutar Claude Code de forma desatendida?

Una VPS dedicada y económica, usada sólo para el trabajo del agente: puede reforzarla en diez minutos, crear una instantánea limpia y ejecutar Claude Code con un usuario sin privilegios y el sandbox activado. Mantenga la clave de API en un archivo con permisos 600, use una clave de despliegue por repositorio y realice todo el trabajo en ramas que revise antes de fusionarlas. Si una ejecución falla, revoca un único token y restaura la instantánea. Nada más de su infraestructura se verá afectado.