Skip to main content
Ambientes na nuvem requerem Claude Code na web, que está em visualização de pesquisa para usuários 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, em planos Pro e Max armazenar credenciais de API que as sessões usam sem vê-las, 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: Claude Code na web, o terminal com claude --cloud, Claude Tag, rotinas, o aplicativo móvel Claude e o aplicativo Desktop. 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 Configuração rápida da web; 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:
  • Na web, no aplicativo Desktop e no aplicativo móvel, as sessões 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.
  • 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

Crie, edite e arquive ambientes a partir do seletor de ambiente em claude.ai/code, que você acessa após a integração web. Os ambientes que você cria são pessoais para sua conta; ambientes compartilhados criados por um Proprietário aparecem no mesmo seletor. Veja Ferramentas instaladas para saber o que está disponível sem nenhuma configuração.
1

Abra o seletor de ambiente

Em claude.ai/code, selecione o ícone de nuvem mostrando o nome do ambiente atual, na linha acima da caixa de mensagem. Não há página de configurações ou URL direto para o seletor.
O seletor de ambiente aberto acima da caixa de mensagem em claude.ai/code. O botão de nuvem mostrando o nome do ambiente Default fica na linha acima da caixa de mensagem. O menu aberto lista uma linha Local com rótulos Download e Desktop only, uma seção Cloud onde o ambiente Default é selecionado com uma marca de seleção e mostra um ícone de engrenagem de configurações ao passar o mouse, uma opção Add cloud environment e uma seção Remote Control com instruções de configuração.
2

Adicione ou edite um ambiente

Selecione Add cloud environment, ou passe o mouse sobre um ambiente existente e selecione o ícone de configurações que aparece à direita. O diálogo inclui o nome, nível de acesso à rede, variáveis de ambiente e script de configuração. Quando você edita um ambiente na nuvem existente em um plano Pro ou Max, o diálogo também inclui credenciais de API.
O diálogo New cloud environment. Um campo Name com o placeholder Default, um seletor Network access definido como Trusted com links para a política de rede e níveis de acesso, uma caixa Environment variables mostrando texto placeholder no formato .env com uma nota de que os valores são visíveis para qualquer pessoa que use o ambiente, uma caixa Setup script descrita como um script Bash que é executado quando uma nova sessão é iniciada antes do Claude Code ser lançado, e botões Cancel e Create environment.

​
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.
Cada sessão copia os valores do ambiente uma vez, na inicialização, em variáveis de ambiente ordinárias que qualquer comando que Claude execute pode ler. Como as sessões em execução não releem a configuração, editar ou adicionar variáveis afeta as sessões que você inicia depois; as sessões já em execução mantêm os valores com os quais começaram. Claude Code na web também define algumas variáveis em si mesmo quando inicia uma sessão. Para CLAUDE_AUTOCOMPACT_PCT_OVERRIDE, o valor que Claude Code na web 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 planos Pro e Max, use uma credencial de API em vez disso para uma chave que o proxy do agente pode anexar a uma solicitação. As solicitações que nunca recebem uma credencial estão listadas lá.

​
Adicione credenciais de API

Uma credencial de API é 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 solicitações para os hosts que você lista, depois que cada solicitação sai da VM da sessão. A chave nunca alcança Claude, os comandos que ele executa, ou as variáveis de ambiente da sessão. As credenciais de API estão disponíveis em planos Pro e Max. Elas ainda não estão disponíveis em planos Team ou Enterprise, portanto a seção API credentials não aparece no diálogo de ambiente nesses planos.

​
Requisitos

Dois destes decidem se você pode adicionar uma credencial, e dois decidem se o proxy do agente pode usá-la uma vez adicionada:
  • Função: uma função de administrador da organização em sua organização claude.ai
    • Em Team e Enterprise, Proprietários a mantêm e Administradores não
    • Em Pro e Max, você a mantém em sua própria organização
    • Sem ela, você vê uma nota em vez da lista de credenciais, até mesmo em seus próprios ambientes. Peça a um Proprietário para adicionar a credencial a um ambiente compartilhado e execute suas sessões lá
  • Tipo de ambiente: um ambiente na nuvem hospedado pela Anthropic que já existe. Um ambiente auto-hospedado não tem credenciais de API
  • 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 credenciais

​
Adicione uma credencial

Você adiciona credenciais uma de cada vez a partir do editor de um ambiente que já existe. O diálogo para um novo ambiente não as oferece. Também não há edição. Para alterar os hosts ou o valor de uma credencial, delete-a e adicione-a novamente.
1

Abra as credenciais de API do ambiente

Abra o ambiente para edição em claude.ai/code. No diálogo Update cloud environment, encontre API credentials abaixo de Environment variables. Você vê as credenciais já no ambiente, cada uma com os hosts aos quais se aplica.
2

Adicione a credencial

Selecione Add credential e preencha o formulário. Mantenha o Credential type padrão, Bearer, para uma chave de API que viaja em um cabeçalho de solicitação, e preencha estes campos:
  • Name: um rótulo para a credencial, 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 Credential 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 a credencial

Selecione Connect. A credencial aparece na lista com seus hosts, salva sem o botão Save changes do diálogo. Você não pode visualizar o valor novamente após salvar.
Para confirmar que a credencial 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 solicitação, e a chave não aparece nas variáveis de ambiente da sessão ou em nenhum arquivo. Se a lista marca uma credencial Not sent em vez disso, a nota abaixo dela diz por quê e o que fazer. Duas credenciais cujos hosts se sobrepõem sem corresponder exatamente não recebem nenhum marcador, e o proxy do agente envia apenas uma delas.

​
Quais solicitações recebem a credencial

O proxy do agente anexa uma credencial a uma solicitação quando o host da solicitação corresponde a um que você listou nessa credencial. 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 o proxy do agente pula. A credencial se aplica em cada sessão que é executada no ambiente, quem quer que a tenha iniciado, até você deletá-la.

​
Solicitações que nunca recebem a credencial

O proxy do agente nunca anexa uma credencial que você adiciona a estas solicitações:
  • GitHub: o proxy do GitHub autentica solicitações para GitHub em vez disso, portanto você não precisa de uma credencial de API para isso
  • A API Anthropic e registros de pacotes públicos: solicitações para api.anthropic.com, registry.npmjs.org, jsr.io, npm.jsr.io, pypi.org, files.pythonhosted.org, index.crates.io e proxy.golang.org não passam pelo proxy do agente
  • 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

​
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 em claude.ai/code.

​
Arquive um ambiente

Para arquivar um ambiente, abra-o para edição e selecione Archive. Você não pode excluir um ambiente, apenas arquivá-lo. 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.
  • As credenciais de API no ambiente permanecem anexadas em suas sessões em execução. Delete qualquer uma que você não queira mais antes de arquivar.
  • Nenhuma nova sessão pode ser iniciada em um ambiente arquivado, em qualquer superfície. 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, e caso contrário no primeiro ambiente em sua lista que não é um ambiente bridge Remote Control. Qualquer coisa configurada com o ambiente explicitamente, como uma rotina, não pode iniciar novas sessões nele. Aponte-a para outro ambiente.

​
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 ao lado dos seus pessoais, portanto uma equipe pode padronizar uma configuração em vez de cada membro recriá-la. Crie, edite e arquive ambientes compartilhados a partir da página Cloud environments nas configurações de administrador. Um ambiente compartilhado também abre a partir do seletor de ambiente em claude.ai/code: um Proprietário pode editá-lo lá. Outros membros o veem como somente leitura. Cada ambiente compartilhado tem um nome, um nível de acesso à rede, variáveis de ambiente no formato .env e um script de configuração. Os Proprietários escolhem o ambiente padrão da organização separadamente, em claude.ai/admin-settings/claude-code. Cada sessão de membro em um ambiente compartilhado lê suas variáveis, portanto não inclua segredos nelas. Credenciais de API, que dão às sessões uma chave que elas não podem ler, ainda não estão disponíveis em planos Team ou Enterprise.

​
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. O ícone de nuvem que abre o seletor aparece nas superfícies do aplicativo listadas em O ambiente Default e no editor de rotina; os ambientes pessoais não têm uma página separada nas configurações de sua conta claude.ai.
Os conectores MCP que você ativa em uma sessão ou rotina 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. Você configura conectores por sessão ou por rotina; remova qualquer um que não precise para limitar quais ferramentas Claude pode alcançar. Isso depende do mesmo canal vinculado à Anthropic observado em Segurança e isolamento.

​
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 solicitações para os hosts das credenciais de API do ambiente, outros que os hosts que o proxy do agente pula, não passam por essa lista de permissões. 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. As configurações gerenciadas pelo servidor ainda se aplicam dentro de sessões na nuvem, mas nenhuma delas adiciona domínios à lista de permissões de rede do ambiente.

​
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.
  • Proteção de push: git push funciona apenas contra o branch de trabalho atual da sessão; clonagem, busca e operações de PR funcionam normalmente.
  • Escopo do repositório: as solicitações de API do GitHub e de ativos de lançamento alcançam apenas repositórios anexados à sessão, portanto um script de configuração que baixa ativos de lançamento de um repositório não anexado recebe um 403.
  • Restrições de GraphQL: o proxy serve apenas um conjunto fixado de operações de GraphQL para fluxos de trabalho de solicitação de pull. O proxy rejeita tudo mais no endpoint de GraphQL com um 403 que diz This GraphQL query is not enabled for this session e nomeia o fallback REST, gh api repos/{owner}/{repo}/.... A restrição se aplica a cada solicitaçã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
  • Filtragem de conteúdo para segurança aprimorada
  • Uma trilha de auditoria no nível de DNS dos nomes de host solicitados

​
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 e os limites de recursos que cada VM obtém.
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

As sessões na nuvem começam a partir de um clone fresco de seu repositório. Qualquer coisa que você confirme 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, confirme-a 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 planos Pro e Max, armazene uma chave que o proxy do agente pode anexar como uma credencial de API em vez disso.

​
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 slash; 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 lista de permissões padrão. Instale-as com um script de configuração.

​
Trabalhe com problemas e solicitações de pull do GitHub

As sessões na nuvem incluem ferramentas GitHub integradas que permitem a Claude ler problemas, listar solicitações de pull, 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 solicitações de saída do GitHub. gh funciona 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 um comando gh que as ferramentas integradas não cobrem, como gh release ou gh workflow run, peça a Claude para executá-lo. 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. Isso requer v2.1.179 ou posterior. Para omitir o trailer e o link do corpo de PR, defina attribution.sessionUrl como false. A configuração requer v2.1.182 ou posterior. 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.

​
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. Para adicionar um script de configuração, abra o diálogo de configurações do ambiente e insira seu script no campo Setup script. Este exemplo instala ShellCheck, que não está pré-instalado.

​
Requisitos do script

Um script de configuração tem três 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. 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.
  • 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.

​
Cache do ambiente

O script de configuração é executado na primeira vez que você inicia uma sessão em um ambiente. Depois que é concluído, 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. 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. Retomar uma sessão existente nunca re-executa o script de configuraçã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:

​
Instale dependências com um hook SessionStart

Para instalar dependências apenas em sessões na nuvem, 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:
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. Juntos, os dois arquivos dão a cada sessão na nuvem um npm install e pip install fresco na inicialização enquanto deixam as sessões locais intocadas.

​
Limitações em sessões na nuvem

Os hooks SessionStart se comportam da mesma forma na nuvem que localmente, com essas ressalvas:
  • Sem escopo apenas na nuvem: os hooks são executados em sessões locais e na nuvem. Para pular a execução local, verifique a variável de ambiente CLAUDE_CODE_REMOTE conforme mostrado acima.
  • 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 verificando se as dependências já estão presentes antes de reinstalar.
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
  • statsig.anthropic.com
  • docs.claude.com
  • platform.claude.com
  • code.claude.com
  • claude.ai
  • github.com
  • www.github.com
  • api.github.com
  • npm.pkg.github.com
  • raw.githubusercontent.com
  • pkg-npm.githubusercontent.com
  • objects.githubusercontent.com
  • release-assets.githubusercontent.com
  • codeload.github.com
  • avatars.githubusercontent.com
  • camo.githubusercontent.com
  • gist.github.com
  • gitlab.com
  • www.gitlab.com
  • registry.gitlab.com
  • bitbucket.org
  • www.bitbucket.org
  • api.bitbucket.org
  • registry-1.docker.io
  • auth.docker.io
  • index.docker.io
  • hub.docker.com
  • www.docker.com
  • production.cloudflare.docker.com
  • download.docker.com
  • gcr.io
  • *.gcr.io
  • ghcr.io
  • mcr.microsoft.com
  • *.data.mcr.microsoft.com
  • public.ecr.aws
  • cloud.google.com
  • accounts.google.com
  • gcloud.google.com
  • *.googleapis.com
  • storage.googleapis.com
  • compute.googleapis.com
  • container.googleapis.com
  • azure.com
  • portal.azure.com
  • microsoft.com
  • www.microsoft.com
  • *.microsoftonline.com
  • packages.microsoft.com
  • dotnet.microsoft.com
  • dot.net
  • visualstudio.com
  • dev.azure.com
  • *.amazonaws.com
  • *.api.aws
  • oracle.com
  • www.oracle.com
  • java.com
  • www.java.com
  • java.net
  • www.java.net
  • download.oracle.com
  • yum.oracle.com
  • proxy.golang.org
  • sum.golang.org
  • index.golang.org
  • golang.org
  • www.golang.org
  • goproxy.io
  • pkg.go.dev
  • maven.org
  • repo.maven.org
  • central.maven.org
  • repo1.maven.org
  • repo.maven.apache.org
  • jcenter.bintray.com
  • gradle.org
  • www.gradle.org
  • services.gradle.org
  • plugins.gradle.org
  • kotlinlang.org
  • www.kotlinlang.org
  • spring.io
  • repo.spring.io
  • dl.k8s.io (Kubernetes)
  • pkgs.k8s.io
  • k8s.io
  • www.k8s.io
  • releases.hashicorp.com (HashiCorp)
  • apt.releases.hashicorp.com
  • rpm.releases.hashicorp.com
  • archive.releases.hashicorp.com
  • hashicorp.com
  • www.hashicorp.com
  • repo.anaconda.com (Anaconda/Conda)
  • conda.anaconda.org
  • anaconda.org
  • www.anaconda.com
  • anaconda.com
  • continuum.io
  • apache.org (Apache)
  • www.apache.org
  • archive.apache.org
  • downloads.apache.org
  • eclipse.org (Eclipse)
  • www.eclipse.org
  • download.eclipse.org
  • nodejs.org (Node.js)
  • www.nodejs.org
  • developer.apple.com
  • developer.android.com
  • pkg.stainless.com
  • binaries.prisma.sh
  • statsig.com
  • www.statsig.com
  • api.statsig.com
  • sentry.io
  • *.sentry.io
  • downloads.sentry-cdn.com
  • http-intake.logs.datadoghq.com
  • browser-intake-us5-datadoghq.com
  • *.datadoghq.com
  • *.datadoghq.eu
  • api.honeycomb.io
  • sourceforge.net
  • *.sourceforge.net
  • packagecloud.io
  • *.packagecloud.io
  • fonts.googleapis.com
  • fonts.gstatic.com
  • *.modelcontextprotocol.io