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

En el modo Manual, Claude Code pide confirmación antes de actuar. La lectura de archivos dentro del proyecto se realiza de forma silenciosa, pero al editar un archivo o ejecutar un comando de shell muestra primero la edición o el comando exactos y espera una respuesta afirmativa. Puede aprobar una acción o indicarle que no vuelva a preguntar. La segunda opción permanece activa hasta que termina la sesión para las ediciones de archivos, pero para un comando de shell se guarda de forma permanente para ese repositorio y comando. Por tanto, una confirmación rápida en un servidor seguirá vigente después de que termine la sesión. Si quiere conservar determinadas reglas de forma deliberada, el archivo de configuración contiene listas persistentes de permisos, confirmaciones y denegaciones. Por ejemplo: permitir git status, pedir confirmación para git push y denegar las lecturas de .env. Las reglas de denegación siempre tienen prioridad. Esa configuración base también ha cambiado. El modo Automático, en el que un clasificador revisa las acciones en lugar de usted, se convirtió en el modo predeterminado para las sesiones nuevas de los planes Pro, Max y Team el 14 de agosto de 2026. Desde Claude Code v2.1.283, también es el modo inicial integrado para las sesiones interactivas de terminal y VS Code en todos los planes, salvo que haya fijado un modo predeterminado. Por eso conviene saber qué permite realmente cada modo de permisos antes de decidir cuál debe ejecutarse en un servidor que no puede supervisar.

Este diseño presupone que una persona está supervisando la terminal. En un portátil, normalmente es así. En un servidor, a menudo nadie está supervisando. Inicia una tarea larga dentro de tmux y se va a dormir. Si un agente se detiene para hacer una pregunta a las 2 a. m., no avanzará hasta la mañana. La pausa cuesta tiempo y dinero, porque una sesión inactiva de Claude Code pierde su caché de prompts activa y el siguiente turno debe pagar el coste de reconstruirla. Esa es la razón real por la que se usa la opción de omitir confirmaciones en los servidores. El problema que resuelve es real. El resto de esta guía explica 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 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 aplicar 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 el flag 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 frente a una lista de permitidos. La primera vez que un comando necesita un dominio nuevo, Claude Code le pregunta. En modo automático, el clasificador revisa el nuevo host.

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 cuándo falta algún componente, y la documentación del sandbox de Claude Code incluye el perfil corto de AppArmor que corrige el problema.

El sandbox tiene un modo de autorización automática: los comandos aislados se ejecutan sin mostrar ningún aviso, porque ahora el límite impuesto realiza la función que antes cumplía el aviso. Los comandos que no pueden ejecutarse dentro del sandbox vuelven al flujo normal de permisos, por lo que las acciones realmente inusuales siguen solicitando confirmación. Para la mayoría de los flujos de trabajo de servidores, este es el reemplazo correcto del flag skip, porque reduce mucho las preguntas y mantiene un límite impuesto por el sistema operativo, en lugar de eliminarlo.

Sea consciente de sus limitaciones. 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 lo que una autorización amplia como github.com todavía permite extraer datos. Docker no funciona dentro del sandbox. El sandbox mejora mucho el nivel mínimo de protección. No es un límite de aislamiento completo, por lo que los niveles siguientes siguen siendo importantes.

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.

Proteja las credenciales

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

Entregue la clave de API al agente y a nadie más. Guárdela en un archivo propiedad del usuario del agente, con permisos 600, y cárguela al iniciar 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 la otra vía. En instalaciones antiguas de Debian y Ubuntu, y en la cuenta creada durante la instalación, los directorios personales pueden ser legibles por cualquier usuario del sistema. Restrinja el suyo: chmod 750 /home/youruser. Compruebe el resultado con ls -ld /home/* y corrija todo lo que la cuenta del agente pueda listar.

Limite el alcance de cada token. Un token de GitHub con permisos detallados y limitado a un único repositorio, o una clave de despliegue 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 lecturas. Mantenga también las credenciales de producción completamente 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 otro 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

Cada cambio que confirma el agente se puede revisar y revertir. Git ofrece ambas capacidades sin coste adicional si el agente trabaja en una rama y confirma los cambios a medida que avanza:

git switch -c agent/refactor-auth

Los cambios que el agente nunca confirma no tienen esa protección: git reset --hard descarta los cambios no confirmados de los archivos bajo seguimiento, y git no cubre nada que esté fuera del repositorio. Revise después la ejecución con git diff main...agent/refactor-auth para comprobar qué confirmó. Después, ejecute git status y git diff HEAD en la rama para encontrar lo que dejó sin confirmar. Integre los cambios útiles y elimine la rama si la ejecución no produjo resultados. Una ejecución que modifica tres archivos es mucho más fácil de revisar durante el desayuno que otra que reescribe 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 desde 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 confirmaciones también sirve como registro de auditoría de lo que ocurrió mientras dormía. Esto vale más que cualquier cantidad de desplazamiento por la salida de 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.