SpyBara
Go Premium

cloud-environments.md 2026-10-06 23:59 UTC to 2026-10-07 19:00 UTC

This page contains 100 additions and 82 deletions.

2026
Thu 1 23:59 Fri 2 22:59 Sat 3 23:57 Sun 4 23:58 Wed 7 20:57

Configurar entornos en la nube

Configure entornos en la nube para sesiones en la nube de Claude Code: niveles de acceso a la red, variables de entorno, scripts de configuración y almacenamiento en caché de entornos.

Cada sesión en la nube se ejecuta en un entorno en la nube. Puedes 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 secretos de red que las sesiones utilizan sin verlos, 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: la aplicación de escritorio, la aplicación móvil de Claude, su navegador en claude.ai/code, la terminal con claude --cloud, routines y Claude Tag. 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.

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 Crea tu primer entorno en la nube a menos que un Propietario haya activado la Configuración rápida; mantén los valores predeterminados del formulario y haz 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 aplicación de escritorio, la aplicación móvil y en claude.ai/code, las sesiones que inicia usted mismo 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. Los hilos en un proyecto utilizan el entorno establecido en la configuración del proyecto en su lugar.
  • 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, al que accede en claude.ai/code después de la incorporación web, o desde el cuadro de mensaje en la aplicación de escritorio. 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 Cloud para enumerar sus entornos. Luego 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 editas un entorno en la nube existente en un plan Pro o Max, el diálogo también incluye secretos de red.

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.

NODE_ENV=development
LOG_LEVEL=debug
DATABASE_URL=postgres://localhost:5432/myapp

Una sesión lee los valores del entorno en variables de entorno ordinarias que cualquier comando que ejecute Claude puede leer, excepto las variables OTEL_*. Claude Code utiliza esas para su propia exportación de telemetría y no las pasa a los comandos que ejecuta.

En un entorno alojado por Anthropic, una sesión lee los valores del entorno cuando lo crea y nuevamente cada vez que Claude Code inicia en la VM de la sesión después, lo que sucede en dos casos:

  • La VM se restaura después de estar inactiva: después de unos minutos sin actividad, la VM de una sesión se pausa con sus archivos guardados. Su siguiente mensaje restaura la misma VM e inicia Claude Code nuevamente.
  • La VM fue reclamada y se reconstruye: si la VM pausada ha sido reclamada, reabriendo la sesión se aprovisiona una VM nueva.

Después de editar, agregar o eliminar una variable, una sesión existente en un entorno alojado por Anthropic mantiene los valores que leyó por última vez hasta que su VM se restaure o reconstruya nuevamente, y utiliza su cambio a partir de entonces. Su VM se pausa por sí sola una vez que la sesión está inactiva, y no puede pausarla usted mismo. Para usar un nuevo valor de inmediato, pida a Claude que lo establezca en el comando que ejecuta, por ejemplo LOG_LEVEL=trace npm test, o inicie una nueva sesión.

Una sesión en la nube también establece algunas variables por sí misma cuando inicia. Para CLAUDE_AUTOCOMPACT_PCT_OVERRIDE, el valor que la sesión 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, usa en su lugar un secreto de red para una clave que el proxy del agente pueda adjuntar a una solicitud. Las solicitudes que nunca obtienen un secreto se enumeran allí.

Agregar secretos de red

Un secreto de red es una clave de API o token que almacenas 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 enumeras, después de que cada solicitud sale de la VM de la sesión. La clave nunca llega a Claude, a los comandos que ejecuta ni a las variables de entorno de la sesión.

Los secretos de red están disponibles en planes Pro y Max. Aún no están disponibles en planes Team o Enterprise, por lo que la sección Secretos de red no aparece en el diálogo de entorno en esos planes.

Requisitos

Dos de estos deciden si puedes agregar un secreto, y dos deciden si el proxy del agente puede usarlo una vez agregado:

  • 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
  • Tipo de entorno: un entorno en la nube alojado por Anthropic que ya existe. Un entorno autohospedado no tiene secretos de red
  • Accesibilidad de API: la API acepta conexiones desde internet, porque las solicitudes salen de la red de Anthropic
  • Claves de cifrado: si tu organización utiliza claves de cifrado administradas por el cliente, no puedes guardar secretos de red

Agregar un secreto

Agregas secretos uno a la vez, y no puedes editar un secreto después de agregarlo. Para cambiar los hosts o el valor de un secreto, elimínalo y agrégalo de nuevo.

1

Abrir los secretos de red del entorno

Abre el entorno para editar en claude.ai/code. En el diálogo Editar entorno, busca la sección Secretos de red. Ves los secretos que ya están en el entorno, cada uno con los hosts a los que se aplica.

2

Agregar el secreto

Selecciona Agregar secreto y completa el formulario. Mantén el Tipo de credencial predeterminado, Bearer, para una clave de API que viaja en un encabezado de solicitud, y completa estos campos:

  • Nombre: una etiqueta para el secreto, como Internal billing API
  • 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; pega la clave misma como el Valor. Para un encabezado como X-Api-Key que toma el valor sin prefijo, cambia el nombre y borra el prefijo

Para una API que se autentica de otra manera, elige 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 el secreto

Selecciona Conectar. El secreto aparece en la lista con sus hosts, guardado sin el botón Guardar cambios del diálogo. No puedes ver el valor nuevamente después de guardar.

Para confirmar que el secreto funciona, inicia una sesión en el entorno y pide 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 en cambio la lista marca un secreto como No enviado, la nota debajo dice por qué y qué hacer. Dos secretos cuyos hosts se superponen sin coincidir exactamente no obtienen marcador, y el proxy del agente envía solo uno de ellos.

Qué solicitudes obtienen el secreto

El proxy del agente adjunta un secreto a una solicitud cuando el host de la solicitud coincide con uno que enumeraste en ese secreto. 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 nunca obtienen el secreto. El secreto se aplica en cada sesión que se ejecuta en el entorno, quienquiera que la haya iniciado, hasta que lo elimines.

Solicitudes que nunca obtienen el secreto

El proxy del agente nunca adjunta un secreto que agregues a estas solicitudes:

  • GitHub: el proxy de GitHub autentica en su lugar las solicitudes a GitHub, por lo que no necesitas un secreto de red para él
  • La API de Anthropic y registros de paquetes públicos: api.anthropic.com, registry.npmjs.org, jsr.io, npm.jsr.io, pypi.org, files.pythonhosted.org, index.crates.io y proxy.golang.org
  • 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
  • Exportación de telemetría de Claude Code: Claude Code envía su propia exportación de telemetría en lugar de a través de un comando que ejecuta, y esa solicitud no pasa por el proxy del agente

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 desde el selector de entornos.

Archivar un entorno

Para archivar uno de sus propios entornos, ábralo para editar y seleccione Archivar. Un Propietario archiva un entorno compartido desde la página Entornos en la nube en la configuración de administrador. 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.
  • Los secretos de red del entorno permanecen adjuntos en sus sesiones en ejecución. Elimina los que ya no desees 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 bajo un encabezado Organización, después de los entornos propios del miembro bajo Personal, por lo que un equipo puede estandarizar una configuración en lugar de que cada miembro la recree. Seleccionar el icono de configuración de un entorno compartido allí abre un resumen de solo lectura de su configuración para cada miembro, incluyendo Propietarios.

Un Propietario pone un entorno a disposición de la organización de una de dos formas:

  • Crear un entorno compartido: use la página Entornos en la nube en configuración de administrador, que es también donde los Propietarios editan y archivan entornos compartidos. Cada uno tiene un nombre, un nivel de acceso a la red, variables de entorno en formato .env y un script de configuración.
  • Compartir un entorno personal: abra uno de sus propios entornos para editar en el selector de entornos, luego compártalo desde la fila Quién puede usarlo. El entorno mantiene su ID, por lo que las sesiones y routines que ya lo usan no se ven afectadas, y cada miembro puede entonces verlo e iniciar sesiones en él.

Los Propietarios eligen el entorno predeterminado de la organización por separado, en claude.ai/admin-settings/claude-code.

Las sesiones de cada miembro en un entorno compartido leen sus variables, por lo que no incluyas secretos en ellas. Los secretos de red, 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. Un entorno compartido se abre como solo lectura allí, por lo que un Propietario cambia su acceso a la red desde la página Cloud environments en configuración de administrador en su lugar. 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.

Cuando cambia el acceso a la red de un entorno alojado por Anthropic, sus sesiones existentes siguen la nueva configuración dentro de aproximadamente un minuto, para solicitudes que pasan por la lista permitida de red de la sesión. No necesita iniciar una nueva sesión.

Niveles de acceso

El campo Network access en el diálogo de entorno toma uno de cuatro niveles:

Nivel Conexiones salientes
None Sin acceso a la red saliente a través de la red de la sesión
Trusted Solo dominios en la lista permitida: registros de paquetes, GitHub, SDK en la nube
Full Cualquier dominio
Custom Su propia lista permitida, opcionalmente incluyendo los valores predeterminados

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.

api.example.com
*.internal.example.com
registry.example.com

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 de conectores MCP y las solicitudes a los hosts de los secretos de red del entorno, excepto los hosts que nunca reciben el secreto, no pasan por esta lista de permitidos. Un *. inicial coincide con cada subdominio. Para mantener también los dominios Trusted, marca Also include default list of common package managers; déjalo sin marcar para permitir solo lo que enumeras.

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. Ninguna configuración administrada por servidor agrega dominios a la lista permitida de red del entorno tampoco. Para dar a un equipo una lista estándar, un Propietario puede crear un entorno compartido de la organización con acceso a la red Custom y esa lista.

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.
  • Restricciones de push: el proxy rechaza las eliminaciones de ramas y los pushes de cualquier cosa que no sea una rama, como una etiqueta. No limita qué ramas puede actualizar un push. Para eso, usa reglas de protección de ramas o rulesets en GitHub.
  • 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 que ejecuta Ubuntu 24.04 en x86_64, independientemente de tu propio sistema operativo y arquitectura de CPU, con tu repositorio clonado y cadenas de herramientas comunes preinstaladas. Cuando una dependencia proporciona binarios precompilados, como gemas de Ruby con extensiones nativas o wheels de Python precompilados, usa su compilación de Linux x86_64 para que coincida con la VM. Esta sección cubre los valores predeterminados alojados por Anthropic, las herramientas integradas de GitHub, cómo ejecutar pruebas y servicios, los límites de recursos que obtiene cada VM y los límites de tiempo en trabajos de larga duración.

Qué se transfiere de tu configuración

Las sesiones en la nube comienzan desde un clon nuevo de tu repositorio. Todo lo que confirmes en el repositorio está disponible. Todo lo que hayas instalado o configurado solo en tu propia máquina no está disponible en la sesión. La política de tu organización llega por separado a través de la configuración administrada por servidor.

Disponible en sesiones en la nube Por qué
El CLAUDE.md de tu repositorio Sí Parte del clon
Los hooks y reglas de permisos de .claude/settings.json de tu repositorio Sí, en una sesión con un repositorio Parte del clon. Una sesión con varios repositorios, incluido un hilo de proyecto, comienza por encima de los clones y no los lee
Los servidores MCP de .mcp.json de tu repositorio Sí, en una sesión con un repositorio Parte del clon, encontrado desde el directorio de trabajo de la sesión
El .claude/rules/ de tu repositorio Sí Parte del clon
Los .claude/skills/, .claude/agents/, .claude/commands/ de tu repositorio Sí Parte del clon
Plugins y marketplaces declarados en el .claude/settings.json de tu repositorio No Una sesión en la nube no instala los plugins que un repositorio activa bajo enabledPlugins, incluidos los de los marketplaces que enumera bajo extraKnownMarketplaces
La configuración administrada por servidor de tu organización Sí, excepto en sesiones de Claude Tag Se obtiene de los servidores de Anthropic cuando comienza la sesión. Consulta Cobertura de superficie para ver cómo se aplica availableModels en sesiones en la nube. La configuración implementada en tu dispositivo a través de MDM o archivos de configuración administrada no se aplica, porque la sesión se ejecuta en una VM administrada por Anthropic; en un entorno autohospedado, las sesiones también leen el archivo de configuración administrada en la imagen del ejecutor, según cómo Claude Code combina fuentes administradas
Tu ~/.claude/CLAUDE.md de usuario No Vive en tu máquina, no en el repositorio. Consulta Agregar preferencias personales sin hacer commit en el repositorio
Tus ~/.claude/skills/, ~/.claude/agents/, ~/.claude/commands/ de usuario No Viven en tu máquina, no en el repositorio. Haz commit de ellos en el directorio .claude/ del repositorio en su lugar. Las sesiones en la nube cargan automáticamente los skills que habilitas en claude.ai
Plugins habilitados solo en tu configuración de usuario No El enabledPlugins con alcance de usuario vive en ~/.claude/settings.json en tu máquina
Servidores MCP que agregaste con claude mcp add en el alcance local predeterminado o el alcance de usuario No Esos escriben en ~/.claude.json en tu máquina, no en el repositorio. Agrega el servidor con claude mcp add --scope project, que escribe el .mcp.json del repositorio, y haz commit de ese archivo. Una sesión con un repositorio lo carga
Variables de transporte en el bloque env de .claude/settings.json de tu repositorio, como NODE_EXTRA_CA_CERTS y las variables de certificado de cliente mTLS No El entorno de alojamiento administra la conexión de API de la sesión, por lo que Claude Code ignora estas claves y anota cada clave ignorada en el registro de depuración de la sesión
Claves de API y tokens para servicios que Claude llama En planes Pro y Max, como secretos de red Agregas la clave una vez en el entorno y el proxy del agente la adjunta a las solicitudes de los hosts que enumeras. Una clave que el proxy del agente no puede adjuntar, o cualquier clave en un plan Team o Enterprise, permanece en una variable de entorno
Autenticación interactiva como AWS SSO No No compatible. SSO requiere un inicio de sesión basado en navegador que no puede ejecutarse en una sesión en la nube

Para que tu propia configuración esté disponible en sesiones en la nube, haz commit de ella en el repositorio.

Cualquiera que use el entorno puede leer sus variables de entorno y su script de configuración. La nota del diálogo en Variables de entorno lo indica y advierte que no pongas secretos allí. En planes Pro y Max, almacena una clave que el proxy del agente pueda adjuntar como un secreto de red en su lugar.

Agregar preferencias personales sin hacer commit en el repositorio

En un entorno alojado por Anthropic, agrega un script de configuración que escriba ~/.claude/CLAUDE.md para las preferencias que prefieras no poner en un repositorio compartido. Claude Code carga ese archivo como instrucciones de usuario en la sesión. Este ejemplo establece una preferencia de mensajes de commit:

#!/bin/bash
mkdir -p ~/.claude
cat > ~/.claude/CLAUDE.md <<'EOF'
Use conventional commit messages.
EOF

Pon el script en uno de tus propios entornos en lugar de en uno compartido.

Ejecuta /context en tu próxima sesión en la nube y confirma que /root/.claude/CLAUDE.md aparece en Memory files.

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.

Categoría Incluido
Python Python 3.x con pip, poetry, uv, black, mypy, pytest, ruff
Node.js 20, 21 y 22, con npm, yarn, pnpm, bun¹, eslint, prettier, chromedriver
Ruby 3.1, 3.2, 3.3 con gem, bundler, rbenv
PHP 8.3 con Composer
Java OpenJDK 21 con Maven y Gradle
Go Go con soporte de módulos
Rust rustc y cargo
C/C++ GCC, Clang, cmake, ninja, conan
Docker docker, dockerd, docker compose
Bases de datos PostgreSQL 16, Redis 7.0
Utilidades git, gh, jq, yq, ripgrep, tmux, vim, nano

¹ Bun está instalado pero tiene problemas de compatibilidad con el proxy conocidos para la obtención de paquetes.

Para obtener las versiones de la mayoría de las herramientas de esta tabla, pide 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 comando que escribas con /; se lo pides a Claude porque Claude ejecuta todos los comandos de la VM por ti. Para una herramienta que no reporta, como Ruby, PHP, bun, PostgreSQL o Redis, pide a Claude que ejecute el comando de versión propio 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, pide 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 de dominios permitidos predeterminada. Instálalas con un script de configuración.

Trabajar con issues y pull requests de GitHub

Las sesiones en la nube incluyen herramientas integradas de GitHub que permiten a Claude leer issues, enumerar pull requests, obtener diffs y publicar comentarios sin ninguna configuración. Estas herramientas se autentican a través del proxy de GitHub utilizando el método que configuraste en Opciones de autenticación de GitHub, por lo que tu token nunca entra en el contenedor.

Puedes establecer GH_TOKEN o GITHUB_TOKEN tú mismo en la configuración del entorno, o dejar ambos sin establecer y dejar que el proxy de GitHub se autentique por ti:

  • Si estableces un token, pasa al contenedor sin cambios, por lo que tus scripts y la CLI gh de GitHub lo usan directamente.
  • Si no estableces ninguno y el proxy de GitHub está manejando la autenticación de tu 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 tus credenciales reales en las solicitudes salientes a 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 establezcas 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 de la VM de la sesión.

Para verificar qué caso se aplica a tu sesión, pide a Claude que ejecute echo $GH_TOKEN.

La CLI gh de GitHub está preinstalada. Si necesitas un comando gh que las herramientas integradas no cubran, como gh release o gh workflow run, pide a Claude que lo ejecute. gh lee GH_TOKEN automáticamente, por lo que no necesitas 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. Úsala para poner un enlace rastreable en cuerpos de PR, mensajes de commit, publicaciones de Slack o informes generados para que un revisor pueda abrir la ejecución que los produjo.

Los commits que Claude crea en una sesión en la nube incluyen un trailer de git Claude-Session: <url>, y los cuerpos de PR incluyen la URL de la sesión en su propia línea. Para omitir el trailer y el enlace del cuerpo del PR, establece attribution.sessionUrl en false.

Para incluir el enlace de la sesión en algo que no sea un commit o un PR, como un mensaje de Slack que Claude publica o un archivo de informe que escribe, pide a Claude que ejecute el siguiente comando y use su salida. El comando convierte el prefijo cse_ del valor de la variable de entorno al prefijo session_ que espera la URL de transcripción:

echo "https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID/#cse_/session_}"

Ejecutar pruebas, iniciar servicios y agregar paquetes

No obtienes un shell en la VM de la sesión. Claude ejecuta cada comando por ti, así que formula las tareas de esta sección como solicitudes en tu prompt.

Ejecutar pruebas

Claude ejecuta pruebas como parte del trabajo en una tarea. Pídelo en tu prompt, por ejemplo "corrige las pruebas fallidas en tests/" o "ejecuta 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 tu proyecto declara como dependencia, como jest, se instala con tus dependencias.

Iniciar servicios

PostgreSQL y Redis están preinstalados pero no se ejecutan de forma predeterminada. Pide a Claude que inicie el que necesites; los comandos que ejecuta son:

service postgresql start

service redis-server start

Docker está disponible para ejecutar servicios en contenedores. Pide a Claude que ejecute docker compose up para iniciar los servicios de tu proyecto. El acceso a la red para extraer imágenes sigue el nivel de acceso de tu entorno, y los valores predeterminados Trusted incluyen Docker Hub y otros registros comunes.

Si tus imágenes son grandes o lentas de extraer, agrega docker compose pull o docker compose build a tu script de configuración. La caché del entorno conserva las imágenes extraídas, por lo que cada sesión nueva las tiene en el disco. La caché almacena solo archivos, no procesos en ejecución, por lo que Claude aún inicia los contenedores en cada sesión.

Agregar paquetes

Para agregar paquetes que no están preinstalados, usa un script de configuración. La caché del entorno conserva lo que instala el script, por lo que los paquetes que instales allí están disponibles al inicio de cada sesión sin reinstalarlos cada vez. También puedes 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 que superen estos límites, usa Remote Control para ejecutar Claude Code en tu propio hardware, o ejecuta sesiones en la nube en un entorno autohospedado en infraestructura de cómputo que opere tu organización.

Límites de tiempo

En entornos alojados por Anthropic, estos límites de tiempo se aplican a trabajos de larga duración en una sesión en la nube, como una compilación, una instalación o una ejecución de pruebas. Cada entrada enlaza a la sección que define el límite.

  • Comandos que ejecuta Claude: un entorno en la nube no establece su propio tiempo de espera de comandos, por lo que se aplican los valores predeterminados de la herramienta Bash. Claude espera 2 minutos por un comando en primer plano de forma predeterminada y puede solicitar hasta 10 minutos.

    Cuando un comando alcanza su tiempo de espera, Claude Code lo mueve a segundo plano en lugar de detenerlo, a menos que el comando comience con sleep. Un comando movido de esta manera puede seguir ejecutándose hasta 30 minutos más antes de que Claude Code lo detenga en su límite de tiempo en segundo plano. Establecer BASH_DEFAULT_TIMEOUT_MS por encima de 1800000 milisegundos alarga ese límite, así como el valor predeterminado en primer plano.

  • Hooks SessionStart: Claude Code cancela un hook command después de 600 segundos a menos que establezcas timeout, en segundos, en la entrada del hook. Claude Code no aplica el tiempo de espera a un hook que ejecutes con async: true.

  • Script de configuración: un script que tarda más de aproximadamente cinco minutos no se almacena en caché. Requisitos del script explica cómo mantenerte por debajo de ese límite.

  • Sesiones inactivas: después de unos minutos sin actividad, la VM de una sesión se pausa con sus archivos guardados, y una VM pausada puede recuperarse más tarde. Establecer variables de entorno describe qué recoge una sesión en cada caso, y Entorno expirado explica cómo reabrir una sesión cuya VM fue recuperada.

Para aumentar los tiempos de espera de comandos de las sesiones de un entorno, agrega BASH_DEFAULT_TIMEOUT_MS y BASH_MAX_TIMEOUT_MS a sus variables de entorno. Ambas toman milisegundos. Por ejemplo, BASH_DEFAULT_TIMEOUT_MS=600000 hace que 10 minutos sea el valor predeterminado.

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.

#!/bin/bash
apt update && apt install -y shellcheck

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. Cuando la configuración tarda más que eso, el entorno no se almacena en caché. 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. Si las nuevas sesiones se atascan o fallan durante la configuración, consulte Las nuevas sesiones se cuelgan o agotan el tiempo de espera durante la configuración.
  • 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. Cuando la configuración se completa dentro de aproximadamente cinco minutos, 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. Si la configuración tarda más de aproximadamente cinco minutos, el entorno no se almacena en caché.

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. En un entorno alojado por Anthropic, el script de configuración no se ejecuta cuando la VM de una sesión se restaura después de estar inactiva, por lo que un cambio en el script llega a una sesión existente solo cuando su VM fue reclamada y se reconstruye. Para aplicar un cambio de inmediato, ejecute los comandos en la sesión o inicie una nueva sesió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.

Scripts de configuración Hooks SessionStart
Dónde los configura El diálogo de entorno en claude.ai/code, más la página Entornos en la nube del administrador para entornos compartidos Un archivo de configuración como su .claude/settings.json del repositorio; consulte Qué se transfiere de su configuración para ver qué archivos llegan a una sesión en la nube
Cuándo se ejecutan Antes de que se lance Claude Code, omitido cuando existe un entorno en caché Después de que se lance Claude Code, en cada sesión incluyendo reanudadas
Dónde se ejecutan Solo sesiones en la nube Sesiones locales y en la nube

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. Qué otros hooks se ejecutan depende de dónde se ejecute la sesión:

  • Entorno alojado por Anthropic: Claude Code ejecuta hooks del repositorio y de la configuración administrada por servidor de su organización. Las sesiones de Claude Tag no reciben configuración administrada por servidor, por lo que los hooks de la configuración administrada por servidor no se ejecutan allí.
  • 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:

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|resume",
        "hooks": [
          {
            "type": "command",
            "command": "bash \"$CLAUDE_PROJECT_DIR\"/scripts/install_pkgs.sh"
          }
        ]
      }
    ]
  }
}

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:

#!/bin/bash

if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  exit 0
fi

npm install
pip install -r requirements.txt
exit 0

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:

  • Un repositorio por sesión: una sesión con varios repositorios no carga hooks de ningún .claude/settings.json del repositorio, por lo que un hook SessionStart que defina allí no se ejecuta. Instale dependencias para esas sesiones con un script de configuración en su lugar.
  • Sin alcance solo en la nube: los hooks se ejecutan en sesiones locales y en la nube. Para omitir la ejecución local, salga temprano a menos que la variable de entorno CLAUDE_CODE_REMOTE sea true, de la manera que lo hace el script de instalación de dependencias.
  • 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 * docs.claude.com * platform.claude.com * code.claude.com * claude.ai * claude.com * support.claude.com * anthropic.com * [www.anthropic.com](http://www.anthropic.com)
Control de versiones
  • 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
Registros de contenedores
  • registry-1.docker.io
  • auth.docker.io
  • index.docker.io
  • hub.docker.com
  • www.docker.com
  • production.cloudflare.docker.com
  • production.cloudfront.docker.com
  • download.docker.com
  • gcr.io
  • *.gcr.io
  • ghcr.io
  • mcr.microsoft.com
  • *.data.mcr.microsoft.com
  • public.ecr.aws
Plataformas en la nube
  • 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
  • *.r2.cloudflarestorage.com
Administradores de paquetes JavaScript y Node
Administradores de paquetes Python
Administradores de paquetes Ruby
Administradores de paquetes Rust
Administradores de paquetes Go
  • proxy.golang.org
  • sum.golang.org
  • index.golang.org
  • golang.org
  • www.golang.org
  • goproxy.io
  • pkg.go.dev
Administradores de paquetes JVM
  • maven.org
  • repo.maven.org
  • central.maven.org
  • repo1.maven.org
  • repo.maven.apache.org
  • maven.google.com
  • jcenter.bintray.com
  • gradle.org
  • www.gradle.org
  • services.gradle.org
  • plugins.gradle.org
  • plugins-artifacts.gradle.org
  • kotlinlang.org
  • www.kotlinlang.org
  • spring.io
  • repo.spring.io
Otros administradores de paquetes
Distribuciones de Linux
Herramientas de desarrollo y plataformas
  • 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
Servicios en la nube y monitoreo
  • http-intake.logs.datadoghq.com
  • *.datadoghq.com
  • *.datadoghq.eu
  • api.honeycomb.io
Entrega de contenido y espejos
  • sourceforge.net
  • *.sourceforge.net
  • packagecloud.io
  • *.packagecloud.io
  • fonts.googleapis.com
  • fonts.gstatic.com
Esquema y configuración
Model Context Protocol
  • *.modelcontextprotocol.io
  • Cloud sessions reference: inicie, administre y comparta sesiones en la nube
  • Cloud sessions quickstart: conecte GitHub e inicie su primera sesión en la nube
  • Claude Tag: las sesiones que Claude inicia desde Slack se ejecutan en los mismos entornos
  • Routines: las ejecuciones programadas utilizan los mismos entornos y niveles de acceso a la red
  • Remote Control: ejecute sesiones en la red y archivos de su propia máquina en su lugar
  • Entornos autohospedados: ejecute sesiones en la nube en la infraestructura propia de su organización
  • SessionStart hooks: configuración confirmada en el repositorio que se ejecuta en sesiones locales y en la nube
  • Server-managed settings: política de la organización que llega desde la consola de administración