Skip to main content
Ambientes na nuvem se aplicam a sessões na nuvem, que estão disponíveis em planos Pro, Max e Team, e para usuários Enterprise com assentos premium ou assentos Chat + Claude Code.
Cada sessão na nuvem é executada em um ambiente na nuvem. Você pode configurar um ambiente para permitir ou negar acesso à rede, definir variáveis de ambiente para a sessão, armazenar segredos de rede que as sessões usam sem vê-los, e executar um script de configuração antes de Claude começar a trabalhar. Os mesmos ambientes se aplicam em qualquer lugar onde você inicie uma sessão na nuvem: Cada uma dessas superfícies também pode rotear para um ambiente auto-hospedado. Disponibilidade e limitações cobre o que Claude ainda não pode usar quando uma sessão do Claude Tag é executada em um.
Sessões de Remote Control conectam as interfaces web e móvel a uma sessão em sua própria máquina, que usa a rede e os arquivos da sua máquina, não um ambiente na nuvem. Sessões de canal do Claude Tag usam ambientes no nível da organização apenas, seja ambientes compartilhados ou ambientes auto-hospedados.

O ambiente Default

Se você ainda não tem um ambiente, a integração configura o ambiente Default para você. Como depende de onde você se integra:
  • Fluxos CLI como /web-setup: criam Default para você
  • Integração web em Pro e Max: cria Default para você
  • Integração web em Team e Enterprise: mostra um formulário Criar seu primeiro ambiente na nuvem a menos que um Proprietário tenha ativado a Configuração rápida; mantenha os padrões do formulário e clique em Criar e concluir para obter o mesmo ambiente Default
Default não carrega nenhuma configuração própria: Com apenas Default disponível, cada sessão é executada nele. Quando você tem mais de um ambiente, as sessões escolhem um por superfície:
  • No aplicativo Desktop, no aplicativo móvel e em claude.ai/code, as sessões que você inicia usam o ambiente mostrado no seletor. Um padrão da organização definido por um Proprietário preenche a seleção quando você não escolheu um. Threads em um projeto usam o ambiente definido nas configurações do projeto.
  • A partir da CLI, Claude Code usa sua escolha /remote-env, ou volta para o ambiente hospedado pela Anthropic quando sua lista tem um, e caso contrário para o primeiro ambiente em sua lista que não é um ambiente bridge, uma entrada Remote Control registra para representar sua própria máquina em vez de um ambiente na nuvem. Para um ambiente auto-hospedado, passar --environment <environment-id> com seu ID ccpool_ quando você despacha uma sessão substitui a escolha /remote-env e o fallback para essa invocação. Claude Code rejeita IDs env_ hospedados pela Anthropic passados para a flag, portanto use /remote-env para direcioná-los. A flag requer Claude Code v2.1.224 ou posterior.
Configure um ambiente quando o padrão não for suficiente: quando Claude precisa alcançar domínios fora da lista de permissões padrão, precisa de variáveis de ambiente definidas para suas sessões, ou precisa de dependências instaladas antes de começar a trabalhar.

Configure seu ambiente

Adicione, edite e arquive ambientes a partir do seletor de ambiente abaixo da caixa de mensagem, na tela em que você inicia uma nova sessão em claude.ai/code. Para chegar a essa tela, conclua a integração web. Para o aplicativo Desktop, veja Sessões na nuvem. Os ambientes que você cria são pessoais para sua conta; ambientes compartilhados criados por um Proprietário aparecem no seletor junto com eles. Veja Ferramentas instaladas para saber o que está disponível sem nenhuma configuração. O seletor aparece apenas até você enviar a primeira mensagem de uma nova sessão. Para editar o ambiente de uma sessão na nuvem sua que esteja em execução, selecione a seta após o título da sessão, no topo, e depois selecione Edit cloud environment.
1

Abra o seletor de ambiente

Na tela de nova sessão, selecione o primeiro controle na linha abaixo da caixa de mensagem.
2

Adicione ou edite um ambiente

  • Adicione um ambiente: selecione New environment na parte inferior do menu para abrir o diálogo New environment. Preencha o formulário e selecione Add environment. Sua nova sessão então usa o ambiente que você adicionou.
  • Edite um ambiente: encontre a linha dele em Cloud. Se Cloud for uma única linha, selecione-a para abrir a lista. Se seu ambiente não estiver listado em Cloud, selecione a linha More sob esse cabeçalho. Passe o mouse sobre a linha do ambiente e selecione o ícone de configurações que aparece à direita para abrir o diálogo dele.
Ao adicionar um ambiente ou editar um dos seus, selecione a linha Network access, Setup script ou Environment variables do diálogo para abrir essa configuração. Após sua última alteração, salve com Add environment para um novo ambiente ou Save changes para um existente. Para armazenar uma chave que as sessões usam sem vê-la, veja Adicione segredos de rede.

Defina variáveis de ambiente

As variáveis de ambiente usam o formato .env, um par KEY=value por linha. Valores simples não precisam de aspas, e se você colocar um valor entre aspas com um par correspondente, as aspas não se tornam parte do valor. Coloque entre aspas um valor que abrange várias linhas ou contém um #: em um valor sem aspas, # inicia um comentário e o resto da linha é descartado. O exemplo a seguir define três variáveis.
Uma sessão lê os valores do ambiente em variáveis de ambiente ordinárias que qualquer comando que Claude execute pode ler, exceto variáveis OTEL_*. Claude Code usa essas para sua própria exportação de telemetria e não as passa para os comandos que executa. Em um ambiente hospedado pela Anthropic, uma sessão lê os valores do ambiente quando você a cria e novamente cada vez que Claude Code inicia na VM da sessão depois, o que acontece em dois casos:
  • A VM é restaurada após estar ociosa: após alguns minutos sem atividade, a VM de uma sessão pausa com seus arquivos salvos. Sua próxima mensagem restaura a mesma VM e inicia Claude Code novamente.
  • A VM foi recuperada e é reconstruída: se a VM pausada foi recuperada, reabrindo a sessão provisiona uma VM nova.
Depois que você edita, adiciona ou remove uma variável, uma sessão existente em um ambiente hospedado pela Anthropic mantém os valores que leu pela última vez até sua VM ser restaurada ou reconstruída novamente, e usa sua alteração a partir de então. Sua VM pausa por conta própria uma vez que a sessão fica ociosa, e você não pode pausá-la você mesmo. Para usar um novo valor imediatamente, peça a Claude para defini-lo no comando que executa, por exemplo LOG_LEVEL=trace npm test, ou inicie uma nova sessão. Uma sessão na nuvem também define algumas variáveis em si mesma quando inicia. Para CLAUDE_AUTOCOMPACT_PCT_OVERRIDE, o valor que a sessão define substitui um que você adiciona aqui, portanto adicionar essa chave aqui não tem efeito. Qualquer pessoa que use o ambiente pode ler os valores. Em um ambiente hospedado pela Anthropic, use um segredo de rede em vez disso para uma chave que o proxy do agente pode anexar a uma requisição. As requisições que nunca recebem um segredo estão listadas lá.

Adicione segredos de rede

Um segredo de rede é uma chave de API ou token que você armazena em um ambiente na nuvem para que Claude possa chamar essa API de qualquer sessão no ambiente sem ver a chave. O proxy do agente da Anthropic adiciona a chave às requisições para os hosts que você lista, depois que cada requisição sai da VM da sessão, de modo que a própria chave permanece fora da VM. Os segredos de rede estão disponíveis em planos Pro, Max, Team e Enterprise. Para verificar se você mesmo pode adicionar um, veja Requisitos.

Requisitos

Estes requisitos decidem se você pode adicionar um segredo e se o proxy do agente pode usá-lo depois de adicionado:
  • Função: em planos Pro, Max e Team, você pode adicionar e excluir segredos em seus próprios ambientes, qualquer que seja sua função. Em Team e Enterprise, Proprietários têm uma função de administrador da organização em sua organização claude.ai e Administradores não, o que muda o que você vê nestes casos:
    • Seu próprio ambiente no Enterprise: com uma função de administrador da organização, você adiciona e exclui segredos. Sem ela, a linha Network secrets abre a lista de segredos com a nota “Only an organization admin can add or delete network secrets” e sem botão Add secret ou de exclusão. Peça a um Proprietário para adicionar o segredo a um ambiente compartilhado e depois execute suas sessões lá
    • Um ambiente compartilhado: Proprietários adicionam e excluem seus segredos nas configurações de administrador. Sem uma função de administrador da organização, peça a um Proprietário para adicionar o segredo, porque o diálogo do ambiente não tem a seção Network secrets
    • Seu próprio ambiente no Team: sem uma função de administrador da organização, Add secret abre um formulário mais curto que aceita um host
  • Tipo de ambiente: um ambiente na nuvem hospedado pela Anthropic que já existe. Um ambiente auto-hospedado não tem segredos de rede
  • Acessibilidade de API: a API aceita conexões da internet, porque as solicitações saem da rede da Anthropic
  • Chaves de criptografia: se sua organização usa chaves de criptografia gerenciadas pelo cliente, você não pode salvar segredos de rede

Adicione um segredo

Você adiciona segredos um de cada vez. Para alterar os hosts ou o valor de um segredo, exclua-o e adicione-o novamente. Para adicionar um segredo a um ambiente compartilhado, abra-o para edição a partir da página Cloud environments nas configurações de administrador e continue a partir da etapa 2 na seção Network secrets dele. Se você está em um plano Team e não tem uma função de administrador da organização, siga a etapa 1 em seu próprio ambiente e depois preencha o formulário mais curto.
1

Abra os segredos de rede do ambiente

Abra o ambiente para edição em claude.ai/code. No diálogo Edit cloud environment, selecione a linha Network secrets. Você vê os segredos já no ambiente, cada um com os hosts aos quais se aplica.
2

Adicione o segredo

Selecione Add secret, rotulado Add nas configurações de administrador, e preencha o formulário. Mantenha o Secret type padrão, Bearer, para uma chave de API que viaja em um cabeçalho de requisição, e preencha estes campos:
  • Name: um rótulo para o segredo, como Internal billing API
  • Allowed websites: os hosts da API, como api.example.com. Um *. inicial corresponde a cada subdomínio
  • Custom headers: uma linha para o cabeçalho que carrega a chave. A linha começa com Authorization como o Name do cabeçalho e Bearer como seu Prefix; cole a chave em si como o Value. Para um cabeçalho como X-Api-Key que usa o valor simples, altere o nome e limpe o prefixo
Para uma API que se autentica de outra forma, escolha um Secret type diferente. A lista é a mesma que Claude Tag, a integração do Slack para planos Team e Enterprise, oferece para conexões.
3

Salve o segredo

Selecione Add. O segredo aparece na lista com seus hosts, salvo sem o botão Save changes do diálogo. Você não pode visualizar o valor novamente após salvar.
Para confirmar que o segredo funciona, inicie uma sessão no ambiente e peça a Claude para chamar a API, por exemplo com curl. A API responde como se a chave estivesse na requisição, e a chave não aparece nas variáveis de ambiente da sessão ou em nenhum arquivo. Se a lista marca um segredo como Not sent em vez disso, a nota abaixo dele diz por quê e o que fazer. Dois segredos cujos hosts se sobrepõem sem corresponder exatamente não recebem nenhum marcador, e o proxy do agente envia apenas um deles.

Adicione um segredo em um plano Team sem uma função de administrador da organização

Se você está em um plano Team e não tem uma função de administrador da organização, o formulário Add secret aceita um segredo para um host. Selecione a linha Network secrets do seu ambiente e depois Add secret. Preencha estes campos e selecione o botão Add secret do formulário:
  • Host: o único host que recebe o segredo, como api.example.com. O formulário não aceita um curinga *.
  • Name: um rótulo opcional para o segredo
  • Secret type: Token para uma chave que viaja em um cabeçalho de requisição, ou Username and password. Para um token, cole a chave como o Value

Quais requisições recebem o segredo

O proxy do agente anexa um segredo a uma requisição quando o host da requisição corresponde a um que você listou nesse segredo. As sessões podem alcançar esses hosts mesmo quando o nível de acesso à rede do ambiente não permitiria de outra forma, exceto os hosts que nunca recebem o segredo. O segredo se aplica em cada sessão que é executada no ambiente, quem quer que a tenha iniciado, até você excluí-lo.

Requisições que nunca recebem o segredo

O proxy do agente nunca anexa um segredo que você adiciona a estas requisições:
  • GitHub: o proxy do GitHub autentica requisições para o GitHub em vez disso, portanto você não precisa de um segredo de rede para isso
  • A API Anthropic e registros de pacotes públicos: api.anthropic.com, registry.npmjs.org, jsr.io, npm.jsr.io, pypi.org, files.pythonhosted.org, index.crates.io e proxy.golang.org
  • Solicitações de script de configuração: Claude Code se conecta ao proxy do agente quando é lançado, depois que o script de configuração foi executado
  • Exportação de telemetria do Claude Code: Claude Code envia sua exportação de telemetria em si mesma em vez de através de um comando que executa, e essa solicitação não passa pelo proxy do agente

Selecione um ambiente a partir da CLI

Execute /remote-env em seu terminal para escolher o ambiente padrão para sessões na nuvem que você cria a partir da CLI, como claude --cloud. O comando abre um seletor de seus ambientes existentes e salva sua escolha na chave remote.defaultEnvironmentId em suas configurações de usuário, portanto se aplica em cada projeto em sua máquina até você alterar, a menos que a mesma chave seja definida em uma camada de configurações de precedência mais alta, como as configurações do projeto de um repositório. Um ID de ambiente auto-hospedado, que tem a forma ccpool_..., segue uma regra de origem mais rigorosa. Veja remote.defaultEnvironmentId para as camadas de configurações que Claude Code honra isso. /remote-env apenas define o padrão: não inicia uma sessão e não pode adicionar ou editar ambientes. Gerencie-os a partir do seletor de ambiente.

Arquive um ambiente

Para arquivar um de seus próprios ambientes, abra-o para edição, selecione Archive environment e confirme. Se o ambiente estiver compartilhado com sua organização, um Proprietário o arquiva a partir da página Cloud environments nas configurações de administrador, portanto peça a um Proprietário, a menos que você seja um. O arquivamento afeta novas sessões, não as em execução:
  • As sessões já em execução no ambiente continuam funcionando.
  • O ambiente desaparece do seletor e de /remote-env, portanto você não pode escolhê-lo para novas sessões.
  • Os segredos de rede no ambiente permanecem anexados em suas sessões em execução. Exclua qualquer um que você não queira mais antes de arquivar.
  • Nenhuma nova sessão pode ser iniciada em um ambiente arquivado, em qualquer superfície:
    • Padrão CLI salvo: se o ambiente era seu padrão CLI salvo, Claude Code inicia sessões na nuvem da CLI no ambiente hospedado pela Anthropic quando sua lista tem um. Caso contrário, ele as inicia no primeiro ambiente em sua lista que não é um ambiente bridge Remote Control.
    • Configurado explicitamente: qualquer coisa configurada com o ambiente explicitamente, como uma tarefa agendada na nuvem, não pode iniciar novas sessões nele. Aponte-a para outro ambiente.
Quando você não precisar mais de um ambiente hospedado pela Anthropic, arquive-o. Nem o diálogo do ambiente nem a página de administrador Cloud environments têm uma opção para excluir um ambiente hospedado pela Anthropic. Se o ambiente for auto-hospedado, um Proprietário pode excluí-lo a partir da página Cloud environments nas configurações de administrador. Se você não for um Proprietário, peça a um para excluí-lo.

Ambientes compartilhados da organização

Em planos Team e Enterprise, um Proprietário pode criar ambientes na nuvem que são compartilhados com cada membro da organização. O mesmo papel gerencia tudo mais na página Cloud environments do administrador, incluindo ambientes auto-hospedados; a função Admin não pode abrir a página. A lista completa de funções que podem abrir é a para gerenciar configurações gerenciadas pelo servidor. Os ambientes compartilhados aparecem no seletor de ambiente de cada membro sob um cabeçalho Organization, depois dos ambientes pessoais do membro sob Personal, portanto uma equipe pode padronizar uma configuração em vez de cada membro recriá-la. Selecionar o ícone de configurações de um ambiente compartilhado lá abre um resumo somente leitura de sua configuração para cada membro, Proprietários inclusos. Um Proprietário disponibiliza um ambiente para a organização de uma de duas maneiras:
  • Crie um ambiente compartilhado: use a página Cloud environments nas configurações de administrador, que é também onde Proprietários editam e arquivam ambientes compartilhados. Cada um tem um nome, um nível de acesso à rede, variáveis de ambiente no formato .env e um script de configuração.
  • Compartilhe um ambiente pessoal: abra um de seus próprios ambientes para edição no seletor de ambiente, depois compartilhe-o a partir da linha Who can use it. O ambiente mantém seu ID, portanto sessões e tarefas agendadas que já o usam não são afetadas, e cada membro pode então vê-lo e iniciar sessões nele.
Os Proprietários escolhem o ambiente padrão da organização separadamente, em claude.ai/admin-settings/claude-code. Para dar às sessões de um ambiente compartilhado uma chave que elas não podem ler, adicione um segredo de rede ao editar o ambiente na página Cloud environments. Não inclua segredos em suas variáveis, porque as sessões de cada membro as leem.

Defina o ambiente que um canal do Claude Tag usa

Em canais do Claude Tag, Claude trabalha como a identidade compartilhada de sua organização, não como qualquer membro, portanto as sessões de canal usam ambientes no nível da organização apenas, seja ambientes compartilhados ou ambientes auto-hospedados. Para dar a um canal uma cadeia de ferramentas que não é pré-instalada, como .NET, um Proprietário pode criar um ambiente compartilhado a partir da página Cloud environments do administrador com um script de configuração que a instala. Aponte o canal para um ambiente de uma de duas maneiras:

Acesso à rede

Cada ambiente define um nível de acesso à rede, que controla as conexões de saída que suas sessões podem fazer. O nível padrão, Trusted, permite registros de pacotes e outros domínios na lista de permissões; Custom usa sua própria lista de domínios. Para alterar o acesso à rede de um ambiente, abra-o para edição e use o seletor Network access no diálogo. Um ambiente compartilhado abre como somente leitura lá, portanto um Owner altera seu acesso à rede a partir da página Cloud environments nas configurações de administrador. O controle que abre o seletor aparece nas superfícies do aplicativo listadas em O ambiente Default e no editor de tarefas agendadas na nuvem. Os ambientes pessoais não têm uma página separada nas configurações de sua conta claude.ai. Quando você altera o acesso à rede de um ambiente hospedado pela Anthropic, suas sessões existentes seguem a nova configuração dentro de aproximadamente um minuto, para solicitações que passam pela lista de permissões de rede da sessão. Você não precisa iniciar uma nova sessão.
Os conectores MCP que você ativa em uma sessão ou tarefa agendada funcionam sem adicionar seus hosts aos Allowed domains, porque o tráfego do conector viaja através dos servidores da Anthropic em vez da rede da sessão. Isso depende do mesmo canal vinculado à Anthropic observado em Segurança e isolamento. Desative qualquer conector que você não precise para limitar quais ferramentas Claude pode alcançar.

Níveis de acesso

O campo Network access no diálogo de ambiente usa um de quatro níveis: Qualquer que seja o nível que você escolha, as sessões ainda podem alcançar estes, porque cada um usa um caminho que não passa pela lista de permissões de rede da sessão:

Permita domínios específicos

Para permitir domínios que não estão na lista Trusted, selecione Custom nas configurações de acesso à rede do ambiente, depois liste um domínio por linha no campo Allowed domains. Este exemplo permite três hosts que um projeto interno pode precisar.
As sessões neste ambiente agora podem alcançar api.example.com, qualquer subdomínio de internal.example.com e registry.example.com, e nenhum outro domínio através da rede da sessão. Tráfego do GitHub, tráfego do conector MCP e requisições para os hosts dos segredos de rede do ambiente, exceto os hosts que nunca recebem o segredo, não passam por essa allowlist. Um *. inicial corresponde a cada subdomínio. Para manter também os domínios Trusted, marque Also include default list of common package managers; deixe desmarcado para permitir apenas o que você listar. Se sua organização usa artefatos, você não precisa de *.frame.claudeusercontent.com na lista para as sessões lerem. Quando a lista deixa esse host de fora, Claude Code lê o conteúdo do artefato através da conexão da sessão com a Anthropic em vez disso. Mantenha o host em uma lista de permissões em duas situações:
  • Sessões neste ambiente abrem artefatos públicos de outra organização: Claude Code busca aqueles do host diretamente, portanto adicione-o a esta lista.
  • Você está configurando a CLI local ou um executor auto-hospedado: mantenha o host nessa lista de permissões. Veja requisitos de acesso à rede e os requisitos de rede auto-hospedados.
Cada ambiente tem sua própria lista de domínios permitidos; não há uma lista de permissões no nível da organização que os administradores possam enviar para os ambientes de cada membro. Nenhuma configuração gerenciada pelo servidor adiciona domínios à lista de permissões de rede do ambiente. Para dar a um time uma lista padrão, um Owner pode criar um ambiente compartilhado pela organização com acesso à rede Custom e essa lista.

Proxy do GitHub

Em ambientes hospedados pela Anthropic, todas as operações do GitHub passam por um proxy dedicado que mantém suas credenciais reais do GitHub fora da VM da sessão, independentemente do nível de acesso do ambiente. As sessões em um ambiente auto-hospedado autenticam operações git com credenciais que sua implantação fornece; Configurar git cobre as opções, incluindo credenciais cunhadas por sessão e uma opção de entrada para este mesmo proxy. O proxy fornece:
  • Credenciais do Git: o cliente git dentro da VM usa uma credencial com escopo, que o proxy verifica e troca por seu token real do GitHub.
  • Solicitações de API: solicitações das ferramentas GitHub integradas e de gh sob o placeholder proxy-injected, saem com suas credenciais reais substituídas.
  • Restrições de push: o proxy rejeita exclusões de branches e pushes de qualquer coisa que não seja um branch, como uma tag. Ele não limita quais branches um push pode atualizar. Para fazer isso, use regras de proteção de branch ou rulesets no GitHub.
  • Escopo do repositório: o proxy atende requisições da API do GitHub para os repositórios anexados à sessão. Uma requisição de API para outro repositório recebe um 403 cuja mensagem começa com GitHub access to e contém is not enabled for this session. Um arquivo compactado do código-fonte que você busca por meio de uma URL github.com/{owner}/{repo}/archive/ ou codeload.github.com recebe esse mesmo 403 quando o repositório não está anexado, mesmo que seja público.
  • Restrições de GraphQL: o proxy rejeita requisições ao endpoint de GraphQL do GitHub com um 403 cuja mensagem começa com GitHub GraphQL is not available from Claude Code sessions e nomeia o fallback REST, gh api repos/{owner}/{repo}/.... Os subcomandos gh que usam GraphQL, como gh pr e gh issue, recebem o mesmo 403. A restrição se aplica a cada requisição através do proxy independentemente das credenciais que você fornece, portanto um GH_TOKEN que você define recebe o mesmo 403. Claude não pode alcançar APIs do GitHub que existem apenas em GraphQL, como Projects v2, através do proxy.
Os arquivos confirmados de repositórios públicos chegam através de raw.githubusercontent.com, que o proxy de segurança manipula em vez disso. Esse domínio está na lista Trusted padrão, portanto esses arquivos permanecem acessíveis a menos que o nível de acesso do ambiente os exclua.

Proxy de segurança

As sessões na nuvem em ambientes hospedados pela Anthropic são executadas atrás de um proxy de rede HTTP/HTTPS para fins de segurança e prevenção de abuso; em um ambiente auto-hospedado, o tráfego de saída sai através de seu próprio limite de rede em vez disso. Todo o tráfego de internet de saída de uma sessão hospedada pela Anthropic passa por esse proxy, que fornece:
  • Proteção contra solicitações maliciosas
  • Limitação de taxa e prevenção de abuso

O que está disponível em sessões na nuvem

Em ambientes hospedados pela Anthropic, cada sessão obtém uma máquina virtual (VM) fresca executando Ubuntu 24.04 em x86_64, independentemente de seu próprio sistema operacional e arquitetura de CPU, com seu repositório clonado e cadeias de ferramentas comuns pré-instaladas. Quando uma dependência fornece binários pré-compilados, como gems Ruby com extensões nativas ou wheels Python pré-construídos, use sua compilação x86_64 Linux para corresponder à VM. Esta seção cobre os padrões hospedados pela Anthropic, as ferramentas GitHub integradas, como executar testes e serviços, os limites de recursos que cada VM obtém, e os limites de tempo em trabalhos de longa duração.
As sessões que sua organização roteia para um ambiente auto-hospedado são executadas em seus próprios executores em vez disso, com as ferramentas que sua imagem de executor fornece.

O que é transferido de sua configuração

Da configuração de repositório nesta tabela, uma thread na nuvem em um projeto carrega apenas o CLAUDE.md da raiz do repositório, .claude/CLAUDE.md e os arquivos .claude/rules/ que não são específicos de caminho. Veja O que as threads obtêm de seus repositórios.
As sessões na nuvem começam a partir de um clone fresco de seu repositório. Qualquer coisa de que você fizer commit no repositório está disponível. Qualquer coisa que você tenha instalado ou configurado apenas em sua própria máquina não está disponível na sessão. A política de sua organização chega separadamente através das configurações gerenciadas pelo servidor. Para disponibilizar sua própria configuração em sessões na nuvem, faça commit dela no repositório. Qualquer pessoa que use o ambiente pode ler suas variáveis de ambiente e script de configuração. A nota do diálogo em Environment variables diz isso e avisa contra colocar segredos lá. Em um ambiente hospedado pela Anthropic, armazene uma chave que o proxy do agente pode anexar como um segredo de rede em vez disso.

Adicione preferências pessoais sem fazer commit no repositório

Em um ambiente hospedado pela Anthropic, adicione um script de configuração que escreva ~/.claude/CLAUDE.md para preferências que você prefere não colocar em um repositório compartilhado. Claude Code carrega esse arquivo como instruções do usuário na sessão. Este exemplo define uma preferência de mensagem de commit:
Coloque o script em um de seus próprios ambientes em vez de em um compartilhado. Execute /context em sua próxima sessão na nuvem e confirme que /root/.claude/CLAUDE.md aparece em Memory files.

Ferramentas instaladas

As sessões na nuvem vêm com tempos de execução de linguagem comuns, ferramentas de compilação e bancos de dados pré-instalados. A tabela abaixo resume o que está incluído por categoria. ¹ Bun está instalado mas tem problemas de compatibilidade de proxy conhecidos para busca de pacotes. Para obter as versões da maioria das ferramentas nesta tabela, peça a Claude para executar check-tools em uma sessão na nuvem. É um comando shell instalado na VM da sessão, não um comando que você digita com /; você pede a Claude porque Claude executa todos os comandos da VM para você. Para uma ferramenta que não relata, como Ruby, PHP, bun, PostgreSQL ou Redis, peça a Claude para executar o comando de versão próprio da ferramenta, por exemplo psql --version. As versões do Node.js estão instaladas em /opt/node20, /opt/node21 e /opt/node22, com 22 em PATH por padrão. Para trabalhar com uma versão diferente, peça a Claude para prepender o diretório bin dessa versão, como /opt/node20/bin, a PATH. As cadeias de ferramentas fora dessa lista, como o SDK .NET, não estão pré-instaladas mesmo quando seus registros de pacotes estão na allowlist padrão. Instale-as com um script de configuração.

Trabalhe com issues e pull requests do GitHub

As sessões na nuvem incluem ferramentas GitHub integradas que permitem a Claude ler issues, listar pull requests, buscar diffs e postar comentários sem nenhuma configuração. Essas ferramentas se autenticam através do proxy do GitHub usando qualquer método que você configurou em opções de autenticação do GitHub, portanto seu token nunca entra no contêiner. Você pode definir GH_TOKEN ou GITHUB_TOKEN você mesmo nas configurações de ambiente, ou deixar ambos não definidos e deixar o proxy do GitHub autenticar para você:
  • Se você definir um token, ele passa para o contêiner inalterado, portanto seus scripts e o gh CLI do GitHub usam-no diretamente.
  • Se você não definir nenhum e o proxy do GitHub estiver manipulando a autenticação para sua sessão, ambas as variáveis leem como a string placeholder proxy-injected nos comandos que Claude executa, e o proxy substitui suas credenciais reais em requisições de saída do GitHub. As chamadas gh api para repositórios anexados funcionam sem um token seu, mas um script que lê GITHUB_TOKEN diretamente obtém o placeholder, não um token utilizável.
Um token que você define é uma variável de ambiente ordinária, portanto qualquer pessoa que use o ambiente pode lê-lo; o caminho do proxy mantém a credencial fora da configuração do ambiente e da VM da sessão. Para verificar qual caso se aplica à sua sessão, peça a Claude para executar echo $GH_TOKEN. O gh CLI do GitHub está pré-instalado. Se você precisar de uma operação do GitHub que as ferramentas integradas não cobrem, peça a Claude para chamar a API REST com gh api. Os subcomandos gh que usam a API REST, como gh workflow list, também funcionam. O proxy rejeita subcomandos que usam GraphQL, como gh pr e gh issue. gh lê GH_TOKEN automaticamente, portanto você não precisa executar gh auth login. Cada sessão na nuvem tem uma URL de transcrição em claude.ai, e a sessão pode ler seu próprio ID a partir da variável de ambiente CLAUDE_CODE_REMOTE_SESSION_ID. Use isso para colocar um link rastreável em corpos de PR, mensagens de commit, posts do Slack ou relatórios gerados para que um revisor possa abrir a execução que os produziu. Os commits que Claude cria em uma sessão na nuvem incluem um trailer git Claude-Session: <url>, e os corpos de PR incluem a URL da sessão em sua própria linha. Para omitir o trailer e o link do corpo de PR, defina attribution.sessionUrl como false. Para incluir o link da sessão em algo diferente de um commit ou PR, como uma mensagem do Slack que Claude posta ou um arquivo de relatório que ele escreve, peça a Claude para executar o seguinte comando e use sua saída. O comando converte o prefixo cse_ no valor da variável de ambiente para o prefixo session_ que a URL de transcrição espera:

Execute testes, inicie serviços e adicione pacotes

Você não obtém um shell na VM da sessão. Claude executa cada comando para você, portanto expresse as tarefas nesta seção como solicitações em seu prompt.

Execute testes

Claude executa testes como parte do trabalho em uma tarefa. Peça por isso em seu prompt, como “corrigir os testes falhando em tests/” ou “executar pytest após cada alteração.” Os executores de teste que vêm com as cadeias de ferramentas pré-instaladas, como pytest e cargo test, funcionam sem configuração adicional. Um executor que seu projeto declara como uma dependência, como jest, instala com suas dependências.

Inicie serviços

PostgreSQL e Redis estão pré-instalados mas não estão em execução por padrão. Peça a Claude para iniciar o que você precisar; os comandos que ele executa são:
Docker está disponível para executar serviços em contêiner. Peça a Claude para executar docker compose up para iniciar os serviços do seu projeto. O acesso à rede para puxar imagens segue o nível de acesso do seu ambiente, e os padrões Trusted incluem Docker Hub e outros registros comuns. Se suas imagens forem grandes ou lentas para puxar, adicione docker compose pull ou docker compose build ao seu script de configuração. O cache do ambiente mantém as imagens puxadas, portanto cada nova sessão as tem no disco. O cache armazena apenas arquivos, não processos em execução, portanto Claude ainda inicia os contêineres cada sessão.

Adicione pacotes

Para adicionar pacotes que não estão pré-instalados, use um script de configuração. O cache do ambiente mantém o que o script instala, portanto os pacotes que você instala lá estão disponíveis no início de cada sessão sem reinstalar cada vez. Você também pode pedir a Claude para instalar pacotes no meio da sessão, mas essas instalações não se transferem para outras sessões.

Limites de recursos

As sessões na nuvem em ambientes hospedados pela Anthropic são executadas com limites de recursos aproximados que podem mudar ao longo do tempo:
  • 4 vCPUs
  • 16 GB de RAM
  • 30 GB de disco
A VM pode parar tarefas que precisam significativamente mais memória, como grandes trabalhos de compilação ou testes com uso intensivo de memória. Para cargas de trabalho além desses limites, use Remote Control para executar Claude Code em seu próprio hardware, ou execute sessões na nuvem em um ambiente auto-hospedado em computação que sua organização opera.

Limites de tempo

Em ambientes hospedados pela Anthropic, estes limites de tempo se aplicam a trabalhos de longa duração em uma sessão na nuvem, como uma compilação, uma instalação ou uma execução de teste. Cada entrada vincula à seção que define o limite.
  • Comandos que Claude executa: um ambiente na nuvem não define seu próprio timeout de comando, portanto os padrões da ferramenta Bash se aplicam. Claude aguarda 2 minutos por um comando em foreground por padrão e pode pedir até 10 minutos. Quando um comando atinge seu timeout, Claude Code o move para o background em vez de pará-lo, a menos que o comando comece com sleep. Um comando movido dessa forma pode continuar executando por até 30 minutos a mais antes de Claude Code pará-lo em seu limite de tempo de background. Definir BASH_DEFAULT_TIMEOUT_MS acima de 1800000 milissegundos alonga esse limite bem como o padrão de foreground.
  • Hooks SessionStart: Claude Code cancela um hook command após 600 segundos a menos que você defina timeout, em segundos, na entrada do hook. Claude Code não aplica o timeout em um hook que você executa com async: true.
  • Script de configuração: um script que leva mais tempo do que aproximadamente cinco minutos não é armazenado em cache. Requisitos de script cobre como ficar abaixo disso.
  • Sessões inativas: após alguns minutos sem atividade, a VM de uma sessão pausa com seus arquivos salvos, e uma VM pausada pode ser recuperada posteriormente. Defina variáveis de ambiente descreve o que uma sessão pega em cada caso, e Environment expired cobre como reabrir uma sessão cuja VM foi recuperada.
Para aumentar os timeouts de comando para as sessões de um ambiente, adicione BASH_DEFAULT_TIMEOUT_MS e BASH_MAX_TIMEOUT_MS às suas variáveis de ambiente. Ambas levam milissegundos. Por exemplo, BASH_DEFAULT_TIMEOUT_MS=600000 faz 10 minutos o padrão.

Scripts de configuração

Um script de configuração é um script Bash que é executado quando uma nova sessão na nuvem é iniciada, antes do Claude Code ser lançado. Use scripts de configuração para instalar dependências, configurar ferramentas ou buscar qualquer coisa que a sessão precise que não esteja pré-instalada. Os scripts são executados como root no Ubuntu 24.04, portanto apt install e a maioria dos gerenciadores de pacotes de linguagem funcionam.

Adicionar um script de configuração

Para adicionar um script de configuração ao seu próprio ambiente, você pode digitá-lo ou colá-lo, ou carregar um arquivo de texto como setup.sh. Adicione ou edite o ambiente e selecione a linha Setup script. Insira o script na caixa que se abre, ou selecione Choose file para substituir o conteúdo da caixa pelo texto de um arquivo de até 64 KB. Em seguida, selecione Add environment ou Save changes. Este exemplo instala ShellCheck, que não está pré-instalado.

Requisitos do script

Um script de configuração tem quatro restrições para trabalhar:
  • Saia com zero: se o script sair com não-zero, a sessão falha ao iniciar. Anexe || true a comandos não críticos para que uma falha de instalação intermitente não bloqueie a sessão.
  • Termine em cinco minutos: mantenha o tempo de execução total do script em aproximadamente cinco minutos para que o cache do ambiente possa ser construído. Quando a configuração leva mais tempo do que isso, o ambiente não é armazenado em cache. Execute instalações independentes em paralelo com & e wait, e mova qualquer download único que não se encaixe em um hook SessionStart que o inicie em segundo plano. Se novas sessões travam ou expiram durante a configuração, veja Novas sessões travam ou expiram durante a configuração.
  • Acesso à rede para instalações: as instalações de pacotes precisam alcançar registros. O nível Trusted padrão cobre registros de pacotes comuns incluindo npm, PyPI, RubyGems e crates.io; com acesso à rede None, as instalações falham.
  • As variáveis do ambiente ainda não estão definidas: o script é executado antes de a sessão definir as variáveis de ambiente do ambiente. Defina no próprio script qualquer valor de que o script precise.

Cache do ambiente

O script de configuração é executado na primeira vez que você inicia uma sessão em um ambiente. Quando a configuração é concluída em aproximadamente cinco minutos, a Anthropic tira um snapshot do sistema de arquivos e reutiliza esse snapshot como ponto de partida para sessões posteriores. As novas sessões começam com suas dependências, ferramentas e imagens Docker já no disco, e pulam a etapa do script de configuração. Isso mantém a inicialização rápida mesmo quando o script instala cadeias de ferramentas grandes ou puxa imagens de contêiner. Se a configuração leva mais tempo do que aproximadamente cinco minutos, o ambiente não é armazenado em cache. O cache é um snapshot do sistema de arquivos, portanto mantém o que o script de configuração escreve no disco e perde qualquer coisa que estava apenas em execução. Os pacotes que você instala, as imagens Docker que você puxa e os arquivos que você escreve todos se transferem. Um banco de dados que o script iniciou, uma pilha docker compose up ou qualquer outro processo em segundo plano não; inicie aqueles por sessão pedindo a Claude ou com um hook SessionStart. O script de configuração é executado novamente para reconstruir o cache quando você altera o script de configuração do ambiente ou hosts de rede permitidos, e quando o cache atinge sua expiração após aproximadamente sete dias. Em um ambiente hospedado pela Anthropic, o script de configuração não é executado quando a VM de uma sessão é restaurada após estar inativa, portanto uma alteração no script atinge uma sessão existente apenas quando sua VM foi reclamada e é reconstruída. Para aplicar uma alteração imediatamente, execute os comandos na sessão ou inicie uma nova sessão. Você não precisa ativar o cache ou gerenciar snapshots você mesmo.

Scripts de configuração vs. hooks SessionStart

Use um script de configuração para provisionar a própria VM: cadeias de ferramentas e ferramentas CLI que não estão pré-instaladas. Use um hook SessionStart para configuração de projeto que deve ser executada em qualquer lugar, nuvem e local, como npm install. Os scripts de configuração e hooks SessionStart são executados em uma ordem fixa quando uma sessão na nuvem é iniciada. A tabela compara onde você os configura, quando são executados e onde são executados. Se você tem hooks SessionStart em seu ~/.claude/settings.json no nível de usuário, não espere por eles na nuvem: as configurações no nível de usuário ficam em sua máquina. Qual outro hook é executado depende de onde a sessão é executada:
  • Ambiente hospedado pela Anthropic: Claude Code executa hooks das configurações gerenciadas pelo servidor de sua organização e, fora de uma thread de projeto, do repositório. As sessões Claude Tag não recebem configurações gerenciadas pelo servidor, portanto hooks de configurações gerenciadas pelo servidor não são executados lá.
  • Ambiente auto-hospedado: Claude Code também executa os hooks que o operador semeou a partir do ~/.claude/ do host do executor, e os hooks no arquivo de configurações gerenciadas da imagem do executor quando esse arquivo é um das fontes gerenciadas que Claude Code aplica.

Instale dependências com um hook SessionStart

Para instalar dependências apenas em sessões na nuvem fora das threads de um projeto, emparelhe um hook SessionStart com um script que verifica onde está sendo executado. Primeiro, adicione um hook SessionStart ao seu .claude/settings.json do repositório. Esta configuração diz a Claude Code para executar scripts/install_pkgs.sh do seu repositório sempre que uma sessão é iniciada ou retomada:
O matcher limita o hook aos eventos startup e resume, e $CLAUDE_PROJECT_DIR resolve para a raiz do repositório, portanto o hook encontra o script independentemente do diretório de trabalho da sessão. Em seguida, crie o script em scripts/install_pkgs.sh. Ele sai imediatamente fora da nuvem, depois instala suas dependências. Ele pula o npm install enquanto package.json, package-lock.json e o próprio script permanecem inalterados desde a última instalação bem-sucedida:
A verificação CLAUDE_CODE_REMOTE é o que escopa a instalação para sessões na nuvem: a VM do ambiente carrega essa variável como true, nunca é true localmente, portanto em seu laptop o script sai antes de instalar qualquer coisa. Para confirmar que o npm install foi bem-sucedido, inicie uma sessão na nuvem e peça a Claude para mostrar node_modules/.install_pkgs.sha256. O arquivo lista um hash para cada um dos três arquivos. Se o arquivo estiver ausente, peça a Claude para executar npm install e relatar o erro.
Se o npm install lê outros arquivos, como o package.json de um workspace, um .npmrc ou as entradas do seu script postinstall, adicione-os ao comando sha256sum que salva os hashes. Caso contrário, você mantém os pacotes antigos depois que um desses arquivos muda.

Limitações em sessões na nuvem

Os hooks SessionStart se comportam da mesma forma na nuvem que localmente, com essas ressalvas:
  • Um repositório por sessão: em um ambiente hospedado pela Anthropic, uma sessão com vários repositórios não carrega hooks de nenhum .claude/settings.json do repositório, portanto um hook SessionStart que você define lá não é executado. Instale dependências para essas sessões com um script de configuração em vez disso. Para um ambiente auto-hospedado, veja quais configurações do repositório se aplicam.
  • Não nas threads na nuvem de um projeto: uma thread na nuvem em um projeto não executa hooks do .claude/settings.json de um repositório, qualquer que seja o número de repositórios. Em um ambiente hospedado pela Anthropic, instale dependências para threads com um script de configuração. Em um ambiente auto-hospedado, use um hook nas configurações do host do executor em vez disso.
  • Sem escopo apenas na nuvem: os hooks são executados em sessões locais e na nuvem. Para pular a execução local, saia cedo a menos que a variável de ambiente CLAUDE_CODE_REMOTE seja true, da forma que o script de instalação de dependência faz.
  • Requer acesso à rede: os comandos de instalação precisam alcançar registros de pacotes. Se seu ambiente usa acesso à rede None, esses hooks falham. A lista de permissões padrão em Trusted cobre npm, PyPI, RubyGems e crates.io.
  • Compatibilidade de proxy: em ambientes hospedados pela Anthropic, todo o tráfego de saída passa por um proxy de segurança, e alguns gerenciadores de pacotes não funcionam corretamente com isso; Bun é um exemplo conhecido. Em um ambiente auto-hospedado, o tráfego de saída vai através de seu próprio limite de rede em vez disso.
  • Adiciona latência de inicialização: os hooks são executados cada vez que uma sessão é iniciada ou retomada, ao contrário dos scripts de configuração que se beneficiam do cache do ambiente. Mantenha os scripts de instalação rápidos pulando o trabalho que já foi feito, da forma que o script de instalação de dependência faz.
Para personalizar a imagem base, use um script de configuração para instalar o que você precisa no topo da imagem fornecida, ou execute sua própria imagem como um contêiner ao lado de Claude com docker compose. Substituir a imagem base inteiramente ainda não é suportado.

Domínios permitidos padrão

Com acesso à rede Trusted, as sessões podem alcançar os seguintes domínios por padrão. Os domínios marcados com * indicam correspondência de subdomínio curinga, portanto *.gcr.io permite qualquer subdomínio 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
  • 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
  • production.cloudfront.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
  • *.r2.cloudflarestorage.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
  • 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
  • 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
  • http-intake.logs.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