Configurações de Desenvolvimento: Otimizando o Ambiente de Trabalho do Claude

📚 Navegação da Série: O capítulo anterior 45 Agent SDK ensinou a isolar o motor de execução do Claude Code para usá-lo como biblioteca de desenvolvimento. Este capítulo retorna ao terminal local — configurando parâmetros como local de execução, permissões de diretórios, proxies de rede, comportamento de quebras de linha e modelos de IA. Estas cinco configurações de ambiente otimizam a estabilidade do fluxo de trabalho diário.

Vamos começar com um cenário com o qual muitos desenvolvedores já se depararam.

Vários profissionais utilizam o Claude Code por meses sem alterar nenhuma configuração inicial do sistema. Ao receberem um projeto de um cliente contendo repositórios privados, surge a preocupação: "Esse repositório contém códigos não auditados. Se houver scripts maliciosos, a IA poderá executá-los diretamente na minha máquina de desenvolvimento pessoal, expondo chaves SSH locais, credenciais de npm ou arquivos privados." Para mitigar esse risco, o desenvolvedor opta por inspecionar visualmente cada comando exibido no console, mantendo o dedo sobre o atalho Ctrl+C para abortar a execução. Esse nível de monitoramento manual consome tempo e desgasta o foco do desenvolvedor.

Para lidar com isso, a CLI possui ferramentas de isolamento nativas: executar o Claude Code em ambientes de sandbox controlados, containers ou máquinas virtuais, impedindo que scripts do repositório afetem a máquina física do desenvolvedor.

Entender as configurações de desenvolvimento previne falhas de segurança, evita cobranças desnecessárias de tokens e melhora a ergonomia de uso. Detalharemos os cinco tópicos fundamentais a seguir.

Ao ler este capítulo, você obterá:

• O mapeamento das cinco áreas de configuração (sandbox, devcontainer, rede, terminal e modelos) e seus respectivos casos de uso.
• Como ativar e gerenciar o sandbox interno usando o comando /sandbox no console.
• A função do devcontainer em ambientes de desenvolvimento compartilhados e sua diferença em relação ao sandbox.
• Como configurar proxies locais e CA de segurança TLS em ambientes corporativos protegidos por firewalls.
• Como ajustar o layout do terminal, atalhos de quebra de linha (Shift+Enter), notificações e temas visuais, além de gerenciar chaves de modelos de IA para otimizar custos.
• Um exercício prático guiado para ativar o sandbox e verificar a alteração de modelos no repositório de testes.

---

01 Os Cinco Pilares de Configuração do Ambiente do Claude

As configurações do Claude Code não funcionam de forma desconexa. Elas definem os cinco aspectos principais que moldam o espaço de trabalho da IA:

Analogia: Organização do espaço de trabalho de um novo profissional. Ao contratar um desenvolvedor, a TI precisa preparar sua mesa: em qual sala física ele trabalhará (na área comum ou em uma sala de segurança isolada), quais as regras de acesso externo (quais redes e serviços ele pode acessar fora da rede interna), se as ferramentas de trabalho são ergonômicas (ajustes de teclado, monitor, atalhos e tema do terminal) e qual o nível de especialização exigido para o projeto (alocar engenheiros seniores ou assistentes juniores). A estruturação desses aspectos reflete as definições do ambiente da CLI.

Configurações de desenvolvimento do Claude Code:

• Isolamento (Onde a IA atua): Recursos como sandbox ou devcontainer determinam até onde os comandos da IA podem ler e escrever no seu computador.
• Rede (O que a IA acessa): Proxies, rotas e certificados que permitem a comunicação em redes corporativas restritas.
• Ergonomia (Como o terminal interage): Ajustes de quebras de linha, notificações do sistema, temas e atalhos de navegação.
• Modelos (Quem processa a lógica): Definição de modelos (como Opus, Sonnet ou Haiku) para balancear inteligência e custo de processamento.

Mapeamento de configurações de desenvolvimento:

Pilar de Configuração	Problema que Resolve	Cenário Típico de Uso
Sandbox local	Proteção da máquina física sem exigir prompts de confirmação em todos os comandos.	Para executar scripts em projetos privados ou não auditados com segurança.
Devcontainer	Uniformidade de ambiente de desenvolvimento em toda a equipe de engenharia.	Configuração uniforme da esteira em processos automatizados no Docker.
Rede Corporativa	Liberação de tráfego de dados por trás de firewalls e TLS proxies.	Erros de conexão com endpoints oficiais (api.anthropic.com) devido a inspeção de rede corporativa.
Interface do Terminal	Customização ergonômica de digitação, avisos visuais e cores do console.	Tratar comportamento de envio ao usar atalhos de quebra de linha (Shift+Enter).
Modelos de IA	Seleção estratégica de modelos para otimizar o consumo de tokens do projeto.	Evitar uso do modelo mais caro em refatorações de sintaxe ou lint simples.

Identificar a qual categoria o seu problema de configuração pertence evita ajustes incorretos. Falhas de conexão de rede exigem análise de proxies, e não mudanças de modelos de IA.

Das áreas listadas, sandbox, conexões de rede e chaves de modelos de IA são as configurações alteradas mais frequentemente no dia a dia, enquanto devcontainers destinam-se a padrões de times e ergonomia atende a preferências visuais.

💡 Resumo em uma frase: O ambiente de desenvolvimento do Claude Code configura-se em cinco áreas centrais: isolamento local (sandbox/devcontainer), rotas de conexão (rede), ergonomia de uso (terminal) e processamento lógico (modelos).

---

02 Sandbox: Automatizando a Execução de Comandos com Segurança Local

O sandbox de ferramentas do Bash (sandboxed Bash tool) resolve um desafio comum de segurança local.

O Equilíbrio entre Segurança e Autonomia

Configurar as permissões no terminal exige lidar com um dilema comum: garantir que a IA tenha velocidade de execução sem expor a máquina física a comandos destrutivos. A CLI oferece duas abordagens padrão: solicitar autorização manual para cada comando (o que atrasa o fluxo) ou autorizar de forma irrestrita (o que traz riscos de segurança). O sandbox atua como uma solução intermediária equilibrada.

Analogia: Pista de testes automotivos. Uma montadora de veículos não realiza testes de aceleração de novos protótipos em vias públicas urbanas devido ao risco de acidentes. Os testes ocorrem em pistas de testes fechadas e controladas: o asfalto é cercado por barreiras de proteção físicas, impedindo que o carro colida com transeuntes ou saia da área delimitada. O sandbox aplica esse conceito ao terminal: restringe a execução de comandos em nível de sistema operacional, definindo limites rígidos de quais arquivos no disco ou IPs na rede a IA pode acessar de forma livre. O Claude atua sem interrupções de confirmação dentro dos limites da pista de testes, parando para solicitar sua autorização apenas se tentar realizar chamadas fora do escopo configurado.

A documentação oficial explica o funcionamento dessa restrição técnica:

O Bash sandbox permite que o Claude execute comandos no console de forma autônoma, sem interrupções de aprovação. Em vez de autorizar comando por comando, o desenvolvedor define a fronteira de acesso a pastas e redes, cabendo ao sistema operacional restringir os subprocessos que tentarem violar essa regra.

Essa restrição é imposta de forma física pelas bibliotecas do sistema operacional, e não por regras em linguagem natural de fácil desvio.

Ativando a Proteção via Comando /sandbox

O recurso de sandbox é integrado nativamente na CLI do Claude Code. Ele é compatível com macOS, Linux e WSL2, não possuindo suporte para ambientes nativos do Windows (que exigem o uso do WSL2). Para gerenciar as opções, execute no chat:

/sandbox

O comando exibirá uma tela de configurações contendo três abas principais:

• Mode (Modo): Permite alternar entre "Auto-allow" (os comandos dentro do sandbox rodam sem interrupção de confirmação) e o modo de permissões convencionais (solicita aprovação em todos os comandos).
• Overrides (Exceções): Controla se comandos não suportados pelo sandbox podem ser executados fora do ambiente isolado (campo correspondente à chave allowUnsandboxedCommands do settings).
• Config (Estrutura): Exibe a lista ativa de IPs e diretórios que o sandbox permite ler e gravar de forma automatizada.

A tecnologia utilizada para impor o isolamento técnico varia conforme o sistema operacional instalado:

• macOS: Utiliza o framework nativo de isolamento Seatbelt do macOS, dispensando a instalação de pacotes externos no sistema operacional.
• Linux / WSL2: Depende dos utilitários bubblewrap (para criar isolamento de sistemas de arquivos) e socat (para interagir com canais de rede virtualizados). Caso esses pacotes não estejam presentes no sistema, o comando /sandbox apresentará uma tela orientando a realizar a instalação usando o gerenciador de pacotes:

# Instalação no Ubuntu / Debian
sudo apt-get install bubblewrap socat

Por padrão, a regra do sandbox restringe a escrita física apenas dentro do diretório do projeto ativo, exigindo confirmação explícita se a IA tentar interagir com domínios de rede externos pela primeira vez. As opções configuradas via painel /sandbox são salvas localmente no arquivo .claude/settings.local.json da raiz do projeto. Para habilitar a proteção global em todos os repositórios da máquina, adicione a chave sandbox.enabled: true na pasta Home (~/.claude/settings.json).

Atenção à regra de redundância padrão do sistema: se o sandbox falhar na inicialização por ausência de dependências, o Claude Code emitirá um alerta no console e continuará a execução fora do ambiente isolado. Se o seu projeto exige segurança estrita e bloqueio de execução caso o sandbox esteja inativo, configure a chave sandbox.failIfUnavailable: true no settings.

Limitação de Escopo: Apenas Comandos Bash

O sandbox nativo do Claude Code restringe apenas chamadas executadas via ferramenta Bash.

As ferramentas internas de escrita e leitura física (Read e Edit), conexões de servidores MCP locais e scripts disparados via gatilhos de hooks rodam de forma direta na máquina física e não herdam os bloqueios do sandbox de comandos.

A documentação oficial destaca este escopo de atuação:

As ferramentas integradas de arquivo, servidores de integração MCP e gatilhos de hooks continuam rodando de forma direta no sistema operacional do hospedeiro.

O sandbox padrão destina-se a simplificar o fluxo de permissões de comandos locais de rotina. Se a atividade envolve a execução de arquivos com alto grau de desconfiança ou vírus conhecidos, isole a CLI por completo usando containers Docker ou utilize o Claude Code on the web (visualização em nuvem do Capítulo 11).

💡 Resumo em uma frase: O comando /sandbox configura o isolamento técnico para ferramentas Bash no macOS e Linux; os comandos rodam sem interrupções dentro das pastas do projeto, mas as ferramentas de escrita Read/Edit e MCP continuam com acesso direto ao sistema de arquivos local.

---

03 Devcontainers: Ambientes de Desenvolvimento Uniformes via Docker

Enquanto o sandbox atua restringindo comandos no terminal local, os devcontainers (containers de desenvolvimento) isolam a execução do Claude Code em um container Docker independente.

Padronização de Máquinas e Execução sem Supervisão

A adoção de devcontainers resolve dois problemas principais das equipes de tecnologia:

1. Variação de versões entre desenvolvedores: se um desenvolvedor do time usa Node v18 e outro v20, a IA pode propor implementações que geram incompatibilidades de compilação.
2. Execução remota em pipelines: ao deixar a IA rodando tarefas em segundo plano ou em lote durante a noite, isolar o acesso do agente impede que falhas lógicas acessem chaves de SSH locais ou dados privados do computador hospedeiro.

Analogia: Cabine de estudos climatizada. Trabalhar na biblioteca comum (máquina física) deixa suas anotações e pastas expostas na mesa, exigindo que você monitore o espaço físico. Ao reservar uma cabine de estudos individualizada, você utiliza as ferramentas fornecidas pela biblioteca (cadeira padrão, iluminação comum e computador institucional) de forma idêntica a qualquer outro estudante. Suas pastas e chaves residenciais não entram na cabine de testes. O devcontainer funciona como essa cabine: configura um container Docker padrão contendo todas as dependências pré-instaladas pela equipe e isola os processos da IA.

A documentação oficial define a utilidade de contêineres de desenvolvimento:

Os devcontainers definem um ambiente padronizado e isolado de desenvolvimento que roda de forma idêntica para toda a equipe. Com o Claude Code instalado no contêiner, todas as edições e comandos executados rodam dentro da estrutura do Docker, e as melhorias nos arquivos são refletidas no repositório de trabalho local de forma síncrona.

Esta arquitetura garante o isolamento físico sem perder as modificações feitas pelo agente no código do projeto.

Configurando o Devcontainer no Repositório

Para ativar o suporte a devcontainers (que exige o Docker instalado na máquina hospedeira e um editor compatível como VS Code ou JetBrains), adicione a especificação de recursos do Claude Code no arquivo de configuração do projeto .devcontainer/devcontainer.json:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

O bloco features invoca a imagem oficial Claude Code Dev Container Feature para automatizar a instalação e o carregamento das dependências da CLI dentro do Docker. Após atualizar o arquivo JSON, reinicie e reconstrua o container usando o atalho de comandos do VS Code: Dev Containers: Rebuild Container.

Nota de persistência: Como containers Docker são reconstruídos a partir de imagens base, chaves de autenticação armazenadas na pasta de dados padrão da CLI (~/.claude) serão perdidas a cada novo build. Para evitar logins frequentes, monte um volume persistente do Docker apontando para o diretório de dados do Claude.

Mantenha a segurança de compartilhamento de chaves mesmo dentro do Docker, conforme o aviso de segurança oficial:

Utilize containers de desenvolvimento apenas em repositórios conhecidos. Evite expor chaves SSH do host ou tokens de computação em nuvem dentro do container.

Não monte chaves SSH privadas locais no volume do devcontainer; utilize tokens temporários de escopo reduzido para conexões de versionamento.

Quadro Comparativo de Isolamento do Claude Code

Diferenças de arquitetura e isolamento técnico:

Método de Isolamento	Escopo de Restrição	Necessidade de Docker	Perfil de Aplicação
Sandbox Interno (/sandbox)	Restringe apenas comandos executados via Bash.	Não	Agilidade no dia a dia local com redução de prompts.
Devcontainer	Isola toda a esteira do projeto e ferramentas da IA.	Sim	Padronização de times e segurança em execuções de background.
Containers Dedicados (VM)	Isola o sistema operacional em nível de kernel virtual.	Sim / Máquina Virtual	Execução de códigos externos não auditados ou arquivos suspeitos.
Claude Code on the web	Executado na infraestrutura em nuvem da Anthropic.	Não	Uso rápido sem necessidade de preparar ambientes físicos locais.

O isolamento é progressivo:

A escolha do nível de isolamento ideal é determinada pela seguinte diretriz prática:

• Para reduzir prompts em comandos locais do dia a dia — use o sandbox interno via /sandbox.
• Para padronizar o ambiente do time ou automatizar tarefas — configure a esteira usando devcontainers Docker.
• Para analisar códigos suspeitos de fontes desconhecidas — use máquinas virtuais dedicadas ou a versão web em nuvem.

💡 Resumo em uma frase: O devcontainer isola a execução do Claude Code em containers Docker, gerenciados via arquivo .devcontainer/devcontainer.json, sendo recomendado para unificar ambientes de equipe e rodar execuções de forma assíncrona.

---

04 Configurações de Conectividade e Redes Corporativas

Esta seção orienta a resolução de falhas de comunicação e erros de SSL/TLS comuns em ambientes de desenvolvimento sob conexões corporativas.

Problemas com Proxies e Firewalls de Rede

O Claude Code precisa estabelecer conexões seguras com as APIs oficiais do sistema para funcionar. Em ambientes de redes empresariais de segurança restrita, todo o tráfego externo passa por proxies ou TLS decrypters (como TLS Inspection) que geram quebras nas validações de segurança padrão da biblioteca.

Analogia: Central telefônica de controle. A tentativa da CLI de conectar com o servidor externo equivale a tentar realizar uma ligação telefônica direta para fora da empresa a partir do seu ramal. Se a rede interna exige que toda chamada externa passe por uma telefonista (servidor proxy) e receba verificação de segurança (certificado TLS), a chamada falhará até que você configure o ramal para usar a rota da central.

As conexões podem ser definidas usando variáveis de ambiente do terminal ou campos específicos no arquivo settings.

Configurando Variáveis de Proxy no Shell

A CLI do Claude Code respeita as variáveis de configuração de proxy do sistema. Defina os caminhos no terminal antes de inicializar a sessão:

# HTTPS Proxy (Caminho Recomendado)
export HTTPS_PROXY=https://proxy.example.com:8080

# HTTP Proxy
export HTTP_PROXY=http://proxy.example.com:8080

# Exclusões de rotas locais
export NO_PROXY="localhost,127.0.0.1,.internal.company.com"

Nota: A CLI não suporta conexões de proxy do tipo SOCKS. Utilize conexões HTTP ou HTTPS. Caso o proxy requeira autenticação, insira as credenciais na URL no formato http://usuario:senha@proxy.exemplo.com:8080, evitando commitar segredos em arquivos expostos.

Tratamento de Certificados Autoassinados (CA Certs)

Se a infraestrutura da empresa intercepta o tráfego TLS usando certificados de segurança corporativos customizados (自签证书), o NodeJS (motor do Claude Code) rejeitará a conexão por não reconhecer a Autoridade Certificadora. Por padrão, a CLI herda a cadeia de certificados do sistema operacional. Caso ocorram erros de SSL, aponte o arquivo de certificado da empresa no terminal:

export NODE_EXTRA_CA_CERTS=/path/to/your-company-ca.pem

Lista de Liberação de IPs (Whitelist de Firewalls)

Caso os firewalls da rede corporativa exijam o cadastro prévio de endereços permitidos para tráfego (whitelist), libere o acesso aos seguintes domínios do ecossistema:

Domínio Oficial	Finalidade
api.anthropic.com	Requisições de chamadas com o modelo de inteligência artificial.
claude.ai	Validação de login e sessões da conta de usuário.
platform.claude.com	Painel de controle de tokens e assinaturas de desenvolvedor.
downloads.claude.ai	Downloads de atualizações e dependências de pacotes da CLI.
bridge.claudeusercontent.com	Conexão web socket com a extensão oficial do Chrome.
raw.githubusercontent.com	Consulta de novas releases e catálogo de plugins instaláveis.

Se a sua empresa utiliza a infraestrutura do Amazon Bedrock ou Google Vertex AI, libere o tráfego apontando para as URLs de endpoints de nuvem correspondentes aos serviços das provedoras, eliminando a necessidade de liberar os domínios da Anthropic.

Se a sua máquina retornar erros de conexão mesmo após definir proxies, verifique se a cadeia de certificados da empresa está registrada no chaveiro de chaves do sistema operacional (como Keychain no macOS ou Root Store no Windows), pois a CLI herda essas validações automaticamente.

💡 Resumo em uma frase: Resolva erros de conexão corporativa configurando HTTPS_PROXY (SOCKS não suportado) e defina a variável NODE_EXTRA_CA_CERTS para ler certificados autoassinados da rede interna.

---

05 Configurações do Terminal: Quebras de Linha, Temas e Notificações

Pequenos ajustes nas preferências do terminal aumentam o conforto visual e a usabilidade do desenvolvedor.

1. Quebras de Linhas (Shift+Enter vs. Envio de Prompt)

É comum tentar adicionar parágrafos em um prompt usando o atalho Shift+Enter e ver o comando ser submetido de forma inacabada no chat.

Dica de digitação: O comando de atalho Ctrl+J (ou adicionar uma barra invertida \ seguida de Enter) funciona como quebra de linha universal em qualquer terminal de console.

Para liberar o atalho Shift+Enter no seu terminal, execute na CLI:

/terminal-setup

A instrução mapeará os códigos de atalhos de teclados nas configurações do emulador de terminal correspondente, adicionando suporte de quebra de linha.

Compatibilidade de atalhos por emulador de terminal:

Categoria	Suporte a Shift+Enter nativo
iTerm2, Ghostty, Kitty, Windows Terminal, Warp, WezTerm	Sim (Nativo, dispensando configurações adicionais).
VS Code, Cursor, Devin Desktop, Zed, Alacritty	Requer execução do comando /terminal-setup na CLI.
Gnome-Terminal, Editores JetBrains (PyCharm, WebStorm)	Não suportado (Use Ctrl+J ou barra invertida \).

2. Notificações e Sons de Conclusão de Tarefas

Tarefas longas de processamento podem ser executadas em segundo plano. Para evitar monitorar o terminal constantemente, você pode configurar alertas sonoros ou notificações de conclusão.

Por padrão, emuladores como Ghostty, Kitty e iTerm2 enviam alertas visuais nativos no sistema operacional. Para forçar o terminal a soar um alerta sonoro de aviso a cada encerramento de tarefa, adicione a chave preferredNotifChannel no arquivo ~/.claude/settings.json do seu usuário:

{
  "preferredNotifChannel": "terminal_bell"
}

A CLI soará um aviso sonoro sempre que o processamento for concluído ou quando solicitar a aprovação de novas permissões no console.

3. Ajuste de Cores e Temas de Console

Ajuste o contraste de cores do chat com o tema do seu emulador de terminal local digitando:

/theme

Selecione a opção de sincronização automática para que a CLI adapte o contraste visual conforme o esquema de cores ativado no seu sistema operacional (Light ou Dark mode).

💡 Resumo em uma frase: Ajuste atalhos de quebra de linha executando /terminal-setup, configure notificações sonoras de conclusão com preferredNotifChannel: "terminal_bell" e ajuste o contraste visual via /theme.

---

06 Escolha de Modelos de IA e Gestão de Custos

Configurar a alocação de modelos evita gastos excessivos de cota de tokens em tarefas de baixa complexidade.

Analogia: Organização de equipes em restaurante. O gerente não direciona o chef principal (Opus) para a pia para lavar os pratos de rotina da cozinha devido ao custo operacional de suas horas. Tarefas de limpeza e organização são executadas por assistentes juniores (Haiku). O chef principal atua exclusivamente na montagem de receitas exclusivas. Mapear as tarefas de programação entre os modelos de IA segue o mesmo princípio financeiro.

Pseudônimos (aliases) oficiais para carregamento de modelos:

Alias do Modelo	Descrição do Perfil	Indicação de Uso
opus	Modelo topo de linha (Opus).	Para análises estruturais de alta complexidade e lógica abstrata.
sonnet	Modelo intermediário padrão (Sonnet).	Recomendado para o desenvolvimento e correções do dia a dia.
haiku	Modelo leve e veloz (Haiku).	Indicado para validação de erros de sintaxe ou refatorações simples de lint.
opusplan	Modelo híbrido inteligente.	Utiliza o Opus para detalhar a lógica (Plan Mode) e o Sonnet para gerar o código físico.

O alias opusplan equilibra qualidade e economia: ele consome a inteligência do Opus para entender o problema e definir a estratégia no planejamento, e delega a escrita física do código para o Sonnet, reduzindo o faturamento da chamada.

Para configurar o modelo padrão da CLI, você pode usar uma das quatro abordagens por ordem de prioridade:

# Opção 1: Temporária na sessão ativa (Prioridade máxima)
/model sonnet

# Opção 2: Apenas na inicialização do console
claude --model opus

# Opção 3: Através de variáveis de ambiente
export ANTHROPIC_MODEL=sonnet

// Opção 4: Salvar a preferência padrão no settings.json (Prioridade mínima)
{
  "model": "opusplan"
}

A hierarquia de precedência de leitura de configurações de modelo foi detalhada no Capítulo 42.

Controle de Orçamento de Equipe

Em projetos corporativos compartilhados com o time, você pode restringir quais modelos os membros da equipe podem invocar configurando a chave availableModels no JSON principal:

{
  "availableModels": ["sonnet", "haiku"]
}

Essa regra bloqueia o uso do modelo Opus por parte do time de desenvolvimento, controlando os gastos de tokens do projeto.

Para ajustar o nível de profundidade analítica de processamento (effort level), utilize o comando interativo /effort ou insira a palavra-chave ultrathink no prompt para que a IA analise a lógica com maior detalhamento naquela consulta pontual, sem alterar as configurações padrão da CLI.

💡 Resumo em uma frase: Opcione modelos adequando a complexidade da tarefa (opus, sonnet, haiku ou a composição opusplan), controlando o orçamento do time através do bloqueio de modelos no array availableModels.

---

07 Exercício Prático: Ativando o Sandbox e Gerenciando Modelos

Validaremos a configuração do sandbox local e a seleção de modelos em um repositório de testes.

Requisitos: Claude Code instalado na máquina, interpretador Bash operacional (macOS, Linux ou WSL2).

Passo 1: Iniciar a sessão e habilitar o sandbox

No seu terminal do sistema operacional, abra o projeto de testes e digite:

claude

Na janela de chat, execute o comando de diagnóstico do sandbox:

/sandbox

Resultado esperado: O console carrega a interface do sandbox. Mude para a aba Mode e escolha a opção "Auto-allow". Se o sistema operacional for Linux e exibir alertas de dependências, instale os pacotes bubblewrap e socat no seu terminal hospedeiro antes de prosseguir.

Passo 2: Validar o isolamento do comando no sandbox

Solicite a gravação de um arquivo de testes na pasta atual:

Crie o arquivo sandbox-teste.txt escrevendo a mensagem "valida sandbox" no corpo do texto.

Resultado esperado: O Claude executa a criação e escrita do arquivo no disco local de forma direta, sem apresentar prompts de confirmação de permissões de gravação no terminal, pois a ação está no escopo de escrita permitido no diretório local.

Passo 3: Verificar o modelo de processamento ativo

Consulte o status do ambiente:

/status

Resultado esperado: A interface exibe a conta autenticada e indica qual modelo está sendo consumido para responder (geralmente Sonnet).

Passo 4: Alterar o modelo da sessão interativa

Mude o processamento de IA da conversa para o modelo Haiku:

/model haiku

Consulte as informações novamente para validar a alteração:

/status

Resultado esperado: A linha correspondente ao modelo de processamento exibe Haiku, confirmando que a alteração de modelo local foi aplicada com sucesso no chat ativo.

Passo 5: Limpar as alterações de teste

Ajuste o modelo para o valor padrão e remova o arquivo criado:

/model default

Encerre a sessão do Claude Code digitando /exit e remova o arquivo sandbox-teste.txt criado no seu terminal local.

💡 Resumo em uma frase: O exercício prático valida a ativação do sandbox via comando /sandbox, a escrita de arquivos sem interrupções de confirmação, a validação de status da sessão com /status e a alternância de modelos via /model.

---

08 Resumo

As configurações de desenvolvimento permitem estruturar o Claude Code de acordo com os requisitos de segurança do projeto, infraestrutura de rede corporativa e ergonomia do terminal.

Conceitos fundamentais revisados neste capítulo:

Configuração	Diretriz de Uso
Sandbox	Ative via /sandbox no modo auto-allow para rodar comandos Bash de rotina com segurança, sem prompts repetitivos de permissão.
Devcontainers	Utilize o feature oficial no devcontainer.json para criar ambientes de desenvolvimento isolados e uniformes em toda a equipe de engenharia via Docker.
Redes Corporativas	Configure as variáveis HTTPS_PROXY e NODE_EXTRA_CA_CERTS para contornar bloqueios de firewalls e ler chaves de segurança TLS empresariais.
Terminal	Execute /terminal-setup para mapear atalhos de teclado de quebras de linha (Shift+Enter) e ajuste temas usando /theme.
Modelos	Selecione modelos de IA estrategicamente usando aliases (opus, sonnet, haiku) e limite gastos de equipe cadastrando os modelos permitidos no availableModels.

Ajustar estes parâmetros otimiza a produtividade do desenvolvedor e garante a segurança física da máquina local ao interagir com a inteligência artificial.

---

O próximo capítulo, 47 "Modo de Voz", ensinará a interagir por voz. Veremos como configurar e permitir que o Claude Code capte e responda a comandos usando áudio, abrindo novas possibilidades de ergonomia de uso. Nos vemos no próximo capítulo!

---

Leituras Recomendadas

• Conectando Servidores de Integração MCP
• Uso de Modelos de IA de Terceiros
• Antipadrões Comuns de Desenvolvimento com IA

---