Skip to main content
Los entornos en la nube requieren Claude Code en la web, que está en vista previa de investigación para usuarios de Pro, Max y Team, y para usuarios de Enterprise con asientos premium o asientos de Chat + Claude Code.
Cada sesión en la nube se ejecuta en un entorno en la nube. Puede configurar un entorno para permitir o denegar acceso a la red, establecer variables de entorno para la sesión, en planes Pro y Max almacenar credenciales de API que las sesiones utilizan sin verlas, y ejecutar un script de configuración antes de que Claude comience a trabajar. Los mismos entornos se aplican dondequiera que inicie una sesión en la nube: Claude Code en la web, la terminal con claude --cloud, Claude Tag, routines, la aplicación móvil de Claude y la aplicación de escritorio. Cada una de estas superficies también puede enrutar a un entorno autohospedado. Disponibilidad y limitaciones cubre lo que Claude aún no puede usar cuando una sesión de Claude Tag se ejecuta en uno.
Las sesiones de Remote Control conectan las interfaces web y móvil a una sesión en su propia máquina, que utiliza la red y los archivos de su máquina, no un entorno en la nube. Las sesiones de canales de Claude Tag utilizan entornos a nivel de organización únicamente, ya sean entornos compartidos o entornos autohospedados.

​
El entorno Default

Si aún no tiene un entorno, la incorporación configura el entorno Default para usted. Cómo depende de dónde se incorpore:
  • Flujos CLI como /web-setup: crean Default para usted
  • Incorporación web en Pro y Max: crea Default para usted
  • Incorporación web en Team y Enterprise: muestra un formulario Crear su primer entorno en la nube a menos que un Propietario haya activado Configuración rápida de web; mantenga los valores predeterminados del formulario y haga clic en Crear y finalizar para obtener el mismo entorno Default
Default no lleva ninguna configuración propia: Con solo Default disponible, cada sesión se ejecuta en él. Cuando tiene más de un entorno, las sesiones eligen uno por superficie:
  • En la web, la aplicación de escritorio y la aplicación móvil, las sesiones utilizan el entorno que se muestra en el selector. Un valor predeterminado de la organización establecido por un Propietario completa la selección cuando no ha elegido uno.
  • Desde la CLI, Claude Code utiliza su selección de /remote-env, o recurre al entorno alojado por Anthropic cuando su lista tiene uno, y de lo contrario al primer entorno en su lista que no sea un entorno puente, una entrada Remote Control que registra para representar su propia máquina en lugar de un entorno en la nube. Para un entorno autohospedado, pasar --environment <environment-id> con su ID ccpool_ cuando distribuya una sesión anula la selección de /remote-env y el respaldo para esa invocación. Claude Code rechaza los IDs env_ alojados por Anthropic pasados a la bandera, así que use /remote-env para dirigirse a esos. La bandera requiere Claude Code v2.1.224 o posterior.
Configure un entorno cuando el valor predeterminado no sea suficiente: cuando Claude necesita alcanzar dominios fuera de la lista permitida predeterminada, necesita variables de entorno establecidas para sus sesiones, o necesita dependencias instaladas antes de que comience a trabajar.

​
Configurar su entorno

Cree, edite y archive entornos desde el selector de entornos en claude.ai/code, al que accede después de la incorporación web. Los entornos que crea son personales para su cuenta; los entornos compartidos creados por un Propietario aparecen en el mismo selector. Consulte Herramientas instaladas para ver qué está disponible sin ninguna configuración.
1

Abrir el selector de entornos

En claude.ai/code, seleccione el icono de nube que muestra el nombre del entorno actual, en la fila encima del cuadro de mensaje. No hay página de configuración ni URL directa para el selector.
El selector de entornos abierto encima del cuadro de mensaje en claude.ai/code. El botón de nube que muestra el nombre del entorno Default se encuentra en la fila encima del cuadro de mensaje. El menú abierto enumera una fila Local con etiquetas de Descargar y Solo escritorio, una sección Cloud donde el entorno Default está seleccionado con una marca de verificación y muestra un icono de engranaje de configuración al pasar el ratón, una opción Agregar entorno en la nube y una sección Remote Control con instrucciones de configuración.
2

Agregar o editar un entorno

Seleccione Agregar entorno en la nube, o pase el ratón sobre un entorno existente y seleccione el icono de configuración que aparece a la derecha. El diálogo incluye el nombre, nivel de acceso a la red, variables de entorno y script de configuración. Cuando edita un entorno en la nube existente en un plan Pro o Max, el diálogo también incluye credenciales de API.
El diálogo Nuevo entorno en la nube. Un campo Nombre con el texto de marcador de posición Default, un selector de Acceso a la red establecido en Trusted con enlaces a la política de red y niveles de acceso, un cuadro Variables de entorno que muestra texto de marcador de posición en formato .env con una nota de que los valores son visibles para cualquiera que use el entorno, un cuadro Script de configuración descrito como un script Bash que se ejecuta cuando comienza una nueva sesión antes de que se lance Claude Code, y botones Cancelar y Crear entorno.

​
Establecer variables de entorno

Las variables de entorno utilizan formato .env, un par KEY=value por línea. Los valores simples no necesitan comillas, y si cita un valor con un par coincidente, las comillas no se convierten en parte del valor. Cite un valor que abarque varias líneas o contenga un #: en un valor sin comillas, # inicia un comentario y el resto de la línea se descarta. El siguiente ejemplo define tres variables.
Cada sesión copia los valores del entorno una vez, al inicio, en variables de entorno ordinarias que cualquier comando que ejecute Claude puede leer. Debido a que las sesiones en ejecución no vuelven a leer la configuración, editar o agregar variables afecta a las sesiones que inicia después; las sesiones ya en ejecución mantienen los valores con los que comenzaron. Claude Code en la web también establece algunas variables por sí mismo cuando inicia una sesión. Para CLAUDE_AUTOCOMPACT_PCT_OVERRIDE, el valor que Claude Code en la web establece anula uno que agregue aquí, por lo que agregar esa clave aquí no tiene efecto. Cualquiera que use el entorno puede leer los valores. En planes Pro y Max, use una credencial de API en su lugar para una clave que el proxy del agente pueda adjuntar a una solicitud. Las solicitudes que nunca obtienen una credencial se enumeran allí.

​
Agregar credenciales de API

Una credencial de API es una clave de API o token que almacena en un entorno en la nube para que Claude pueda llamar a esa API desde cualquier sesión en el entorno sin ver la clave. El proxy del agente de Anthropic agrega la clave a las solicitudes de los hosts que enumera, después de que cada solicitud sale de la VM de la sesión. La clave nunca llega a Claude, los comandos que ejecuta, o las variables de entorno de la sesión. Las credenciales de API están disponibles en planes Pro y Max. No están disponibles en planes Team o Enterprise aún, por lo que la sección Credenciales de API no aparece en el diálogo de entorno en esos planes.

​
Requisitos

Dos de estos deciden si puede agregar una credencial, y dos deciden si el proxy del agente puede usarla una vez agregada:
  • Rol: un rol de administrador de la organización en su organización claude.ai
    • En Team y Enterprise, los Propietarios lo tienen y los Administradores no
    • En Pro y Max, lo tiene en su propia organización
    • Sin él, ve una nota en lugar de la lista de credenciales, incluso en sus propios entornos. Pida a un Propietario que agregue la credencial a un entorno compartido y ejecute sus sesiones allí
  • Tipo de entorno: un entorno en la nube alojado por Anthropic que ya existe. Un entorno autohospedado no tiene credenciales de API
  • Accesibilidad de API: la API acepta conexiones desde internet, porque las solicitudes salen de la red de Anthropic
  • Claves de cifrado: si su organización utiliza claves de cifrado administradas por el cliente, no puede guardar credenciales

​
Agregar una credencial

Agrega credenciales una a la vez desde el editor de un entorno que ya existe. El diálogo para un nuevo entorno no las ofrece. Tampoco hay edición. Para cambiar los hosts o el valor de una credencial, elimínela y agréguela de nuevo.
1

Abrir las credenciales de API del entorno

Abra el entorno para editar en claude.ai/code. En el diálogo Actualizar entorno en la nube, encuentre Credenciales de API debajo de Variables de entorno. Ve las credenciales ya en el entorno, cada una con los hosts a los que se aplica.
2

Agregar la credencial

Seleccione Agregar credencial y complete el formulario. Mantenga el Tipo de credencial predeterminado, Bearer, para una clave de API que viaja en un encabezado de solicitud, y complete estos campos:
  • Nombre: una etiqueta para la credencial, como API de facturación interna
  • Sitios web permitidos: los hosts de la API, como api.example.com. Un *. inicial coincide con cada subdominio
  • Encabezados personalizados: una fila para el encabezado que lleva la clave. La fila comienza con Authorization como el Nombre del encabezado y Bearer como su Prefijo; pegue la clave misma como el Valor. Para un encabezado como X-Api-Key que toma el valor desnudo, cambie el nombre y borre el prefijo
Para una API que se autentica de otra manera, elija un Tipo de credencial diferente. La lista es la misma que Claude Tag, la integración de Slack para planes Team y Enterprise, ofrece para conexiones.
3

Guardar la credencial

Seleccione Conectar. La credencial aparece en la lista con sus hosts, guardada sin el botón Guardar cambios del diálogo. No puede ver el valor nuevamente después de guardar.
Para confirmar que la credencial funciona, inicie una sesión en el entorno y pida a Claude que llame a la API, por ejemplo con curl. La API responde como si la clave estuviera en la solicitud, y la clave no aparece en las variables de entorno de la sesión ni en ningún archivo. Si la lista marca una credencial No enviada en su lugar, la nota debajo dice por qué y qué hacer. Dos credenciales cuyos hosts se superponen sin coincidir exactamente no obtienen marcador, y el proxy del agente envía solo una de ellas.

​
Qué solicitudes obtienen la credencial

El proxy del agente adjunta una credencial a una solicitud cuando el host de la solicitud coincide con uno que enumera en esa credencial. Las sesiones pueden alcanzar esos hosts incluso cuando el nivel de acceso a la red del entorno no lo permitiría de otra manera, excepto los hosts que el proxy del agente omite. La credencial se aplica en cada sesión que se ejecuta en el entorno, quienquiera que la haya iniciado, hasta que la elimine.

​
Solicitudes que nunca obtienen la credencial

El proxy del agente nunca adjunta una credencial que agregue a estas solicitudes:
  • GitHub: el proxy de GitHub autentica las solicitudes a GitHub en su lugar, por lo que no necesita una credencial de API para él
  • La API de Anthropic y registros de paquetes públicos: las solicitudes a api.anthropic.com, registry.npmjs.org, jsr.io, npm.jsr.io, pypi.org, files.pythonhosted.org, index.crates.io y proxy.golang.org no pasan por el proxy del agente
  • Solicitudes de script de configuración: Claude Code se conecta al proxy del agente cuando se lanza, después de que el script de configuración ha ejecutado

​
Seleccionar un entorno desde la CLI

Ejecute /remote-env en su terminal para elegir el entorno predeterminado para sesiones en la nube que crea desde la CLI, como claude --cloud. El comando abre un selector de sus entornos existentes y guarda su elección en la clave remote.defaultEnvironmentId en su configuración de usuario, por lo que se aplica en cada proyecto en su máquina hasta que lo cambie, a menos que la misma clave esté establecida en una capa de configuración de mayor precedencia, como la configuración del proyecto de un repositorio. Un ID de entorno autohospedado, que tiene la forma ccpool_..., sigue una regla de origen más estricta. Consulte remote.defaultEnvironmentId para las capas de configuración que Claude Code honra. /remote-env solo establece el valor predeterminado: no inicia una sesión, y no puede agregar o editar entornos. Adminístrelos en claude.ai/code.

​
Archivar un entorno

Para archivar un entorno, ábralo para editar y seleccione Archivar. No puede eliminar un entorno, solo archivarlo. El archivado afecta a las nuevas sesiones, no a las que se están ejecutando:
  • Las sesiones ya en ejecución en el entorno continúan funcionando.
  • El entorno desaparece del selector y de /remote-env, por lo que no puede elegirlo para nuevas sesiones.
  • Las credenciales de API en el entorno permanecen adjuntas en sus sesiones en ejecución. Elimine las que ya no desee antes de archivar.
  • Ninguna sesión nueva puede iniciarse en un entorno archivado, en ninguna superficie. Si el entorno era su valor predeterminado de CLI guardado, Claude Code inicia sesiones en la nube de CLI en el entorno alojado por Anthropic cuando su lista tiene uno, y de lo contrario en el primer entorno en su lista que no sea un entorno puente de Remote Control. Cualquier cosa configurada con el entorno explícitamente, como una routine, no puede iniciar nuevas sesiones en él. Apúntela a otro entorno.

​
Entornos compartidos de la organización

En planes Team y Enterprise, un Propietario puede crear entornos en la nube que se comparten con cada miembro de la organización. El mismo rol administra todo lo demás en la página Entornos en la nube del administrador, incluyendo entornos autohospedados; el rol Administrador no puede abrir la página. La lista completa de roles que pueden abrirla es la de administración de configuración administrada por servidor. Los entornos compartidos aparecen en el selector de entornos de cada miembro junto con los suyos personales, por lo que un equipo puede estandarizar una configuración en lugar de que cada miembro la recree. Cree, edite y archive entornos compartidos desde la página Entornos en la nube en configuración de administrador. Un entorno compartido también se abre desde el selector de entornos en claude.ai/code: un Propietario puede editarlo allí. Otros miembros lo ven de solo lectura. Cada entorno compartido tiene un nombre, un nivel de acceso a la red, variables de entorno en formato .env y un script de configuración. Los Propietarios eligen el entorno predeterminado de la organización por separado, en claude.ai/admin-settings/claude-code. Cada sesión de miembro en un entorno compartido lee sus variables, por lo que no incluya secretos en ellas. Las credenciales de API, que dan a las sesiones una clave que no pueden leer, aún no están disponibles en planes Team o Enterprise.

​
Establecer el entorno que usa un canal de Claude Tag

En canales de Claude Tag, Claude trabaja como la identidad compartida de su organización, no como ningún miembro, por lo que las sesiones de canal utilizan entornos a nivel de organización únicamente, ya sean entornos compartidos o entornos autohospedados. Para dar a un canal una cadena de herramientas que no esté preinstalada, como .NET, un Propietario puede crear un entorno compartido desde la página Entornos en la nube del administrador con un script de configuración que lo instale. Apunte el canal a un entorno de una de dos formas:

​
Acceso a la red

Cada entorno establece un nivel de acceso a la red, que controla las conexiones salientes que pueden hacer sus sesiones. El nivel predeterminado, Trusted, permite registros de paquetes y otros dominios en la lista permitida; Custom toma su propia lista de dominios. Para cambiar el acceso a la red de un entorno, ábralo para editar y use el selector Network access en el diálogo. El icono de nube que abre el selector aparece en las superficies de la aplicación enumeradas bajo El entorno Default y en el editor de routines; los entornos personales no tienen una página separada en la configuración de su cuenta claude.ai.
Los conectores MCP que habilita en una sesión o routine funcionan sin agregar sus hosts a Allowed domains, porque el tráfico del conector viaja a través de los servidores de Anthropic en lugar de la red de la sesión. Configura conectores por sesión o por routine; elimina los que no necesites para limitar qué herramientas puede alcanzar Claude. Esto se basa en el mismo canal vinculado a Anthropic anotado bajo Seguridad y aislamiento.

​
Niveles de acceso

El campo Network access en el diálogo de entorno toma uno de cuatro niveles: Cualquiera que sea el nivel que elija, las sesiones aún pueden alcanzar estos, porque cada uno toma una ruta que no pasa por la lista permitida de red de la sesión:

​
Permitir dominios específicos

Para permitir dominios que no están en la lista Trusted, seleccione Custom en la configuración de acceso a la red del entorno, luego enumere un dominio por línea en el campo Allowed domains. Este ejemplo permite tres hosts que un proyecto interno podría necesitar.
Las sesiones en este entorno ahora pueden alcanzar api.example.com, cualquier subdominio de internal.example.com y registry.example.com, y ningún otro dominio a través de la red de la sesión. El tráfico de GitHub, el tráfico del conector MCP y las solicitudes a los hosts de las credenciales de API del entorno, excepto los hosts que el proxy del agente omite, no pasan por esta lista permitida. Un *. inicial coincide con cada subdominio. Para mantener también los dominios Trusted, marque Also include default list of common package managers; déjelo sin marcar para permitir solo lo que enumera. Si su organización utiliza artefactos, no necesita *.frame.claudeusercontent.com en la lista para que las sesiones los lean. Cuando la lista deja ese host fuera, Claude Code lee el contenido del artefacto a través de la conexión de la sesión a Anthropic en su lugar. Mantenga el host en una lista permitida en dos situaciones:
  • Las sesiones en este entorno abren artefactos públicos de otra organización: Claude Code obtiene esos del host directamente, así que agréguelo a esta lista.
  • Está configurando la CLI local o un ejecutor autohospedado: mantenga el host en esa lista permitida. Consulte requisitos de acceso a la red y los requisitos de red autohospedados.
Cada entorno tiene su propia lista de dominios permitidos; no hay una lista permitida a nivel de organización que los administradores puedan enviar a los entornos de cada miembro. La configuración administrada por servidor aún se aplica dentro de sesiones en la nube, pero ninguna de ellas agrega dominios a la lista permitida de red del entorno.

​
Proxy de GitHub

En entornos alojados por Anthropic, todas las operaciones de GitHub pasan por un proxy dedicado que mantiene sus credenciales reales de GitHub fuera de la VM de la sesión, independientemente del nivel de acceso del entorno. Las sesiones en un entorno autohospedado autentican operaciones de git con credenciales que su implementación proporciona; Configurar git cubre las opciones, incluyendo credenciales acuñadas por sesión y una opción de participación en este mismo proxy. El proxy proporciona:
  • Credenciales de Git: el cliente git dentro de la VM utiliza una credencial con alcance, que el proxy verifica e intercambia por su token real de GitHub.
  • Solicitudes de API: las solicitudes de las herramientas integradas de GitHub y de gh bajo el marcador de posición proxy-injected, se envían con sus credenciales reales sustituidas.
  • Protección de push: git push funciona solo contra la rama de trabajo actual de la sesión; la clonación, la obtención y las operaciones de PR funcionan normalmente.
  • Alcance del repositorio: las solicitudes de API de GitHub y de activos de lanzamiento alcanzan solo repositorios adjuntos a la sesión, por lo que un script de configuración que descarga activos de lanzamiento de un repositorio no adjunto obtiene un 403.
  • Restricciones de GraphQL: el proxy sirve solo un conjunto fijado de operaciones de GraphQL para flujos de trabajo de solicitud de extracción. El proxy rechaza todo lo demás en el punto final de GraphQL con un 403 que dice This GraphQL query is not enabled for this session y nombra el respaldo de REST, gh api repos/{owner}/{repo}/.... La restricción se aplica a cada solicitud a través del proxy independientemente de las credenciales que suministre, por lo que un GH_TOKEN que establezca obtiene el mismo 403. Claude no puede alcanzar APIs de GitHub que existen solo en GraphQL, como Projects v2, a través del proxy.
Los archivos confirmados de repositorios públicos llegan a través de raw.githubusercontent.com, que el proxy de seguridad maneja en su lugar. Ese dominio está en la lista Trusted predeterminada, por lo que esos archivos permanecen accesibles a menos que el nivel de acceso del entorno los excluya.

​
Proxy de seguridad

Las sesiones en la nube en entornos alojados por Anthropic se ejecutan detrás de un proxy de red HTTP/HTTPS para fines de seguridad y prevención de abuso; en un entorno autohospedado, el tráfico saliente sale a través de su propio límite de red en su lugar. Todo el tráfico de internet saliente de una sesión alojada por Anthropic pasa por este proxy, que proporciona:
  • Protección contra solicitudes maliciosas
  • Limitación de velocidad y prevención de abuso
  • Filtrado de contenido para mayor seguridad
  • Un registro de auditoría a nivel de DNS de nombres de host solicitados

​
Qué está disponible en sesiones en la nube

En entornos alojados por Anthropic, cada sesión obtiene una máquina virtual (VM) nueva ejecutando Ubuntu 24.04 en x86_64, independientemente de su propio sistema operativo y arquitectura de CPU, con su repositorio clonado y cadenas de herramientas comunes preinstaladas. Cuando una dependencia proporciona binarios precompilados, como gemas de Ruby con extensiones nativas o ruedas de Python precompiladas, use su compilación de Linux x86_64 para coincidir con la VM. Esta sección cubre los valores predeterminados alojados por Anthropic, las herramientas integradas de GitHub, cómo ejecutar pruebas y servicios y los límites de recursos que obtiene cada VM.
Las sesiones que su organización enruta a un entorno autohospedado se ejecutan en sus propios ejecutores en su lugar, con las herramientas que proporciona su imagen de ejecutor.

​
Qué se transfiere de su configuración

Las sesiones en la nube comienzan desde un clon nuevo de su repositorio. Cualquier cosa que confirme en el repositorio está disponible. Cualquier cosa que haya instalado o configurado solo en su propia máquina no está disponible en la sesión. La política de su organización llega por separado a través de configuración administrada por servidor. Para que su propia configuración esté disponible en sesiones en la nube, confirme la en el repositorio. Cualquiera que use el entorno puede leer sus variables de entorno y script de configuración. La nota del diálogo bajo Variables de entorno lo dice y advierte contra poner secretos allí. En planes Pro y Max, almacene una clave que el proxy del agente pueda adjuntar como una credencial de API en su lugar.

​
Herramientas instaladas

Las sesiones en la nube vienen con tiempos de ejecución de lenguaje comunes, herramientas de compilación y bases de datos preinstaladas. La tabla a continuación resume lo que se incluye por categoría. ¹ Bun está instalado pero tiene problemas de compatibilidad conocidos con proxy para obtención de paquetes. Para obtener las versiones de la mayoría de las herramientas en esta tabla, pida a Claude que ejecute check-tools en una sesión en la nube. Es un comando de shell instalado en la VM de la sesión, no un slash command; pide a Claude porque Claude ejecuta todos los comandos de VM para usted. Para una herramienta que no reporta, como Ruby, PHP, bun, PostgreSQL o Redis, pida a Claude que ejecute el comando de versión propia de la herramienta, por ejemplo psql --version. Las versiones de Node.js se instalan en /opt/node20, /opt/node21 y /opt/node22, con 22 en PATH de forma predeterminada. Para trabajar con una versión diferente, pida a Claude que anteponga el directorio bin de esa versión, como /opt/node20/bin, a PATH. Las cadenas de herramientas fuera de esta lista, como el SDK de .NET, no están preinstaladas incluso cuando sus registros de paquetes están en la lista permitida predeterminada. Instálelas con un script de configuración.

​
Trabajar con problemas y solicitudes de extracción de GitHub

Las sesiones en la nube incluyen herramientas integradas de GitHub que permiten a Claude leer problemas, enumerar solicitudes de extracción, obtener diffs y publicar comentarios sin ninguna configuración. Estas herramientas se autentican a través del proxy de GitHub utilizando cualquier método que configuró bajo Opciones de autenticación de GitHub, por lo que su token nunca entra en el contenedor. Puede establecer GH_TOKEN o GITHUB_TOKEN usted mismo en configuración de entorno, o dejar ambos sin establecer y dejar que el proxy de GitHub se autentique por usted:
  • Si establece un token, pasa al contenedor sin cambios, por lo que sus scripts y el gh CLI de GitHub lo usan directamente.
  • Si no establece ninguno y el proxy de GitHub está manejando la autenticación para su sesión, ambas variables se leen como la cadena de marcador de posición proxy-injected en los comandos que ejecuta Claude, y el proxy sustituye sus credenciales reales en solicitudes salientes de GitHub. gh funciona sin un token propio, pero un script que lee GITHUB_TOKEN directamente obtiene el marcador de posición, no un token utilizable.
Un token que establece es una variable de entorno ordinaria, por lo que cualquiera que use el entorno puede leerlo; la ruta del proxy mantiene la credencial fuera de la configuración del entorno y la VM de la sesión. Para verificar qué caso se aplica a su sesión, pida a Claude que ejecute echo $GH_TOKEN. El gh CLI de GitHub está preinstalado. Si necesita un comando gh que las herramientas integradas no cubran, como gh release o gh workflow run, pida a Claude que lo ejecute. gh lee GH_TOKEN automáticamente, por lo que no necesita ejecutar gh auth login. Cada sesión en la nube tiene una URL de transcripción en claude.ai, y la sesión puede leer su propio ID desde la variable de entorno CLAUDE_CODE_REMOTE_SESSION_ID. Úselo para poner un enlace rastreable en cuerpos de PR, mensajes de confirmación, publicaciones de Slack o informes generados para que un revisor pueda abrir la ejecución que los produjo. Las confirmaciones que Claude crea en una sesión en la nube incluyen un remolque de git Claude-Session: <url>, y los cuerpos de PR incluyen la URL de la sesión en su propia línea. Esto requiere v2.1.179 o posterior. Para omitir el remolque y el enlace del cuerpo de PR, establezca attribution.sessionUrl en false. La configuración requiere v2.1.182 o posterior. Para incluir el enlace de la sesión en algo que no sea una confirmación o PR, como un mensaje de Slack que Claude publica o un archivo de informe que escribe, pida a Claude que ejecute el siguiente comando y use su salida. El comando convierte el prefijo cse_ en el valor de la variable de entorno al prefijo session_ que espera la URL de transcripción:

​
Ejecutar pruebas, iniciar servicios y agregar paquetes

No obtiene un shell en la VM de la sesión. Claude ejecuta cada comando para usted, por lo que exprese las tareas en esta sección como solicitudes en su indicación.

​
Ejecutar pruebas

Claude ejecuta pruebas como parte del trabajo en una tarea. Solicítelo en su indicación, como “corregir las pruebas fallidas en tests/” o “ejecutar pytest después de cada cambio”. Los ejecutores de pruebas que vienen con las cadenas de herramientas preinstaladas, como pytest y cargo test, funcionan sin configuración adicional. Un ejecutor que su proyecto declara como una dependencia, como jest, se instala con sus dependencias.

​
Iniciar servicios

PostgreSQL y Redis están preinstalados pero no se ejecutan de forma predeterminada. Pida a Claude que inicie el que necesite; los comandos que ejecuta son:
Docker está disponible para ejecutar servicios en contenedores. Pida a Claude que ejecute docker compose up para iniciar los servicios de su proyecto. El acceso a la red para extraer imágenes sigue su nivel de acceso del entorno, y los valores predeterminados Trusted incluyen Docker Hub y otros registros comunes. Si sus imágenes son grandes o lentas de extraer, agregue docker compose pull o docker compose build a su script de configuración. El almacenamiento en caché del entorno mantiene las imágenes extraídas, por lo que cada sesión nueva las tiene en el disco. El caché almacena solo archivos, no procesos en ejecución, por lo que Claude aún inicia los contenedores cada sesión.

​
Agregar paquetes

Para agregar paquetes que no están preinstalados, use un script de configuración. El almacenamiento en caché del entorno mantiene lo que instala el script, por lo que los paquetes que instala allí están disponibles al inicio de cada sesión sin reinstalar cada vez. También puede pedir a Claude que instale paquetes a mitad de sesión, pero esas instalaciones no se transfieren a otras sesiones.

​
Límites de recursos

Las sesiones en la nube en entornos alojados por Anthropic se ejecutan con límites de recursos aproximados que pueden cambiar con el tiempo:
  • 4 vCPU
  • 16 GB de RAM
  • 30 GB de disco
La VM puede detener tareas que necesitan significativamente más memoria, como trabajos de compilación grandes o pruebas que consumen mucha memoria. Para cargas de trabajo más allá de estos límites, use Remote Control para ejecutar Claude Code en su propio hardware, o ejecute sesiones en la nube en un entorno autohospedado en computación que su organización opera.

​
Scripts de configuración

Un script de configuración es un script Bash que se ejecuta cuando comienza una nueva sesión en la nube, antes de que se lance Claude Code. Use scripts de configuración para instalar dependencias, configurar herramientas o obtener cualquier cosa que la sesión necesite que no esté preinstalada. Los scripts se ejecutan como root en Ubuntu 24.04, por lo que apt install y la mayoría de los administradores de paquetes de lenguaje funcionan. Para agregar un script de configuración, abra el diálogo de configuración del entorno e ingrese su script en el campo Setup script. Este ejemplo instala ShellCheck, que no está preinstalado.

​
Requisitos del script

Un script de configuración tiene tres restricciones para escribir:
  • Salir con cero: si el script sale con un valor distinto de cero, la sesión no se inicia. Agregue || true a comandos no críticos para que una falla de instalación intermitente no bloquee la sesión.
  • Terminar dentro de cinco minutos: mantenga el tiempo de ejecución total del script por debajo de aproximadamente cinco minutos para que el almacenamiento en caché del entorno pueda compilarse. Ejecute instalaciones independientes en paralelo con & y wait, y mueva cualquier descarga única que no quepa a un hook SessionStart que lo inicie en segundo plano.
  • Acceso a la red para instalaciones: las instalaciones de paquetes necesitan alcanzar registros. El nivel Trusted predeterminado cubre registros de paquetes comunes incluyendo npm, PyPI, RubyGems y crates.io; con acceso a la red None, las instalaciones fallan.

​
Almacenamiento en caché del entorno

El script de configuración se ejecuta la primera vez que inicia una sesión en un entorno. Después de que se completa, Anthropic toma una instantánea del sistema de archivos y reutiliza esa instantánea como punto de partida para sesiones posteriores. Las nuevas sesiones comienzan con sus dependencias, herramientas e imágenes de Docker ya en el disco, y omiten el paso del script de configuración. Esto mantiene el inicio rápido incluso cuando el script instala cadenas de herramientas grandes o extrae imágenes de contenedor. El caché es una instantánea del sistema de archivos, por lo que mantiene lo que el script de configuración escribe en el disco y pierde cualquier cosa que solo estaba en ejecución. Los paquetes que instala, las imágenes de Docker que extrae y los archivos que escribe se transfieren. Una base de datos que inició el script, una pila docker compose up o cualquier otro proceso en segundo plano no; inicie esos por sesión pidiendo a Claude o con un hook SessionStart. El script de configuración se ejecuta nuevamente para reconstruir el caché cuando cambia el script de configuración del entorno u hosts de red permitidos, y cuando el caché alcanza su vencimiento después de aproximadamente siete días. Reanudar una sesión existente nunca vuelve a ejecutar el script de configuración. No necesita habilitar el almacenamiento en caché ni administrar instantáneas usted mismo.

​
Scripts de configuración vs. hooks SessionStart

Use un script de configuración para aprovisionar la VM misma: cadenas de herramientas y herramientas CLI que no están preinstaladas. Use un hook SessionStart para configuración del proyecto que debe ejecutarse en todas partes, en la nube y localmente, como npm install. Los scripts de configuración y los hooks SessionStart se ejecutan en un orden fijo cuando comienza una sesión en la nube. La tabla compara dónde los configura, cuándo se ejecutan y dónde se ejecutan. Si tiene hooks SessionStart en su ~/.claude/settings.json a nivel de usuario, no espere que estén en la nube: la configuración a nivel de usuario permanece en su máquina. En una sesión en la nube, Claude Code ejecuta hooks del repositorio y de la configuración administrada por servidor de su organización. En un entorno autohospedado, Claude Code también ejecuta los hooks que el operador sembró desde el ~/.claude/ del host del ejecutor, y los hooks en el archivo de configuración administrada de la imagen del ejecutor cuando ese archivo es uno de los orígenes administrados que Claude Code aplica.

​
Instalar dependencias con un hook SessionStart

Para instalar dependencias solo en sesiones en la nube, empareje un hook SessionStart con un script que verifique dónde se está ejecutando. Primero, agregue un hook SessionStart a su .claude/settings.json del repositorio. Esta configuración le dice a Claude Code que ejecute scripts/install_pkgs.sh de su repositorio cada vez que comienza o se reanuda una sesión:
El matcher limita el hook a los eventos startup y resume, y $CLAUDE_PROJECT_DIR se resuelve a la raíz del repositorio, por lo que el hook encuentra el script independientemente del directorio de trabajo de la sesión. A continuación, cree el script en scripts/install_pkgs.sh. Sale inmediatamente fuera de la nube, luego instala sus dependencias:
La verificación CLAUDE_CODE_REMOTE es lo que limita la instalación a sesiones en la nube: la VM de la sesión lleva esa variable como true, nunca es true localmente, por lo que en su portátil el script sale antes de instalar cualquier cosa. Juntos, los dos archivos dan a cada sesión en la nube un npm install y pip install nuevo al inicio mientras dejan las sesiones locales sin tocar.

​
Limitaciones en sesiones en la nube

Los hooks SessionStart se comportan igual en la nube que localmente, con estas advertencias:
  • Sin alcance solo en la nube: los hooks se ejecutan en sesiones locales y en la nube. Para omitir la ejecución local, verifique la variable de entorno CLAUDE_CODE_REMOTE como se muestra arriba.
  • Requiere acceso a la red: los comandos de instalación necesitan alcanzar registros de paquetes. Si su entorno usa acceso a la red None, estos hooks fallan. La lista permitida predeterminada bajo Trusted cubre npm, PyPI, RubyGems y crates.io.
  • Compatibilidad con proxy: en entornos alojados por Anthropic, todo el tráfico saliente pasa por un proxy de seguridad, y algunos administradores de paquetes no funcionan correctamente con él; Bun es un ejemplo conocido. En un entorno autohospedado, el tráfico saliente va a través de su propio límite de red en su lugar.
  • Agrega latencia de inicio: los hooks se ejecutan cada vez que comienza o se reanuda una sesión, a diferencia de los scripts de configuración que se benefician del almacenamiento en caché del entorno. Mantenga los scripts de instalación rápidos verificando si las dependencias ya están presentes antes de reinstalar.
Para personalizar la imagen base, use un script de configuración para instalar lo que necesita encima de la imagen proporcionada, o ejecute su propia imagen como un contenedor junto a Claude con docker compose. Reemplazar la imagen base completamente aún no es compatible.

​
Dominios permitidos predeterminados

Con acceso a la red Trusted, las sesiones pueden alcanzar los siguientes dominios de forma predeterminada. Los dominios marcados con * indican coincidencia de subdominio comodín, por lo que *.gcr.io permite cualquier subdominio de gcr.io.
  • api.anthropic.com
  • statsig.anthropic.com
  • docs.claude.com
  • platform.claude.com
  • code.claude.com
  • claude.ai
  • github.com
  • www.github.com
  • api.github.com
  • npm.pkg.github.com
  • raw.githubusercontent.com
  • pkg-npm.githubusercontent.com
  • objects.githubusercontent.com
  • release-assets.githubusercontent.com
  • codeload.github.com
  • avatars.githubusercontent.com
  • camo.githubusercontent.com
  • gist.github.com
  • gitlab.com
  • www.gitlab.com
  • registry.gitlab.com
  • bitbucket.org
  • www.bitbucket.org
  • api.bitbucket.org
  • registry-1.docker.io
  • auth.docker.io
  • index.docker.io
  • hub.docker.com
  • www.docker.com
  • production.cloudflare.docker.com
  • download.docker.com
  • gcr.io
  • *.gcr.io
  • ghcr.io
  • mcr.microsoft.com
  • *.data.mcr.microsoft.com
  • public.ecr.aws
  • cloud.google.com
  • accounts.google.com
  • gcloud.google.com
  • *.googleapis.com
  • storage.googleapis.com
  • compute.googleapis.com
  • container.googleapis.com
  • azure.com
  • portal.azure.com
  • microsoft.com
  • www.microsoft.com
  • *.microsoftonline.com
  • packages.microsoft.com
  • dotnet.microsoft.com
  • dot.net
  • visualstudio.com
  • dev.azure.com
  • *.amazonaws.com
  • *.api.aws
  • oracle.com
  • www.oracle.com
  • java.com
  • www.java.com
  • java.net
  • www.java.net
  • download.oracle.com
  • yum.oracle.com
  • proxy.golang.org
  • sum.golang.org
  • index.golang.org
  • golang.org
  • www.golang.org
  • goproxy.io
  • pkg.go.dev
  • maven.org
  • repo.maven.org
  • central.maven.org
  • repo1.maven.org
  • repo.maven.apache.org
  • jcenter.bintray.com
  • gradle.org
  • www.gradle.org
  • services.gradle.org
  • plugins.gradle.org
  • kotlinlang.org
  • www.kotlinlang.org
  • spring.io
  • repo.spring.io
  • dl.k8s.io (Kubernetes)
  • pkgs.k8s.io
  • k8s.io
  • www.k8s.io
  • releases.hashicorp.com (HashiCorp)
  • apt.releases.hashicorp.com
  • rpm.releases.hashicorp.com
  • archive.releases.hashicorp.com
  • hashicorp.com
  • www.hashicorp.com
  • repo.anaconda.com (Anaconda/Conda)
  • conda.anaconda.org
  • anaconda.org
  • www.anaconda.com
  • anaconda.com
  • continuum.io
  • apache.org (Apache)
  • www.apache.org
  • archive.apache.org
  • downloads.apache.org
  • eclipse.org (Eclipse)
  • www.eclipse.org
  • download.eclipse.org
  • nodejs.org (Node.js)
  • www.nodejs.org
  • developer.apple.com
  • developer.android.com
  • pkg.stainless.com
  • binaries.prisma.sh
  • statsig.com
  • www.statsig.com
  • api.statsig.com
  • sentry.io
  • *.sentry.io
  • downloads.sentry-cdn.com
  • http-intake.logs.datadoghq.com
  • browser-intake-us5-datadoghq.com
  • *.datadoghq.com
  • *.datadoghq.eu
  • api.honeycomb.io
  • sourceforge.net
  • *.sourceforge.net
  • packagecloud.io
  • *.packagecloud.io
  • fonts.googleapis.com
  • fonts.gstatic.com
  • *.modelcontextprotocol.io