settings.json: Configurações Globais e Locais (User / Project)

📚 Navegação da Série: O artigo anterior 30 Escolha de Recursos: CLAUDE.md vs Skill vs Hook vs MCP vs Subagent ensinou a direcionar suas demandas técnicas. Este capítulo se aprofunda um nível abaixo—detalhando em qual arquivo físico salvar suas configurações e como gerenciar regras de precedência. O settings.json atua como a central de controle de configurações do Claude Code; hoje, alinharemos suas regras de aplicação.

Há um erro comum e frustrante de configuração que, depois de cometido uma vez, você nunca mais esquecerá.

Ao iniciar os testes com o Claude Code, é comum tentar desabilitar prompts de permissões recorrentes em um repositório adicionando "defaultMode": "auto" no arquivo .claude/settings.json local. O resultado? Nenhuma alteração de comportamento. A primeira suspeita recai sobre um erro de digitação do parâmetro; após conferir a documentação três vezes, constata-se que a sintaxe está perfeita. Em seguida, valida-se o arquivo em um formatador JSON—que confirma sua integridade. Após gastar cerca de vinte minutos depurando o terminal, começa-se a cogitar um possível bug na versão instalada.

A resposta está escondida em uma linha da documentação oficial: o parâmetro defaultMode definido como "auto" é sumariamente ignorado quando salvo em arquivos locais do projeto. Essa é uma restrição de segurança intencional para impedir que repositórios externos forcem execuções autônomas sem a aprovação explícita do desenvolvedor (ponto já abordado no Artigo 20). A sintaxe estava correta e o arquivo íntegro—o erro residia unicamente na escolha da pasta. Mover o bloco de código para o arquivo de escopo global do usuário ~/.claude/settings.json faz a configuração funcionar instantaneamente.

Esse exemplo ilustra que a maioria dos problemas com o settings.json não reside na sintaxe do JSON, mas sim em qual nível a chave é salva e na sua hierarquia de precedência. Neste artigo, explicaremos de forma prática essas "regras de camadas", permitindo que você decida com precisão se um parâmetro deve residir na raiz do sistema ou na pasta do projeto.

Ao terminar este artigo, você obterá:

• Uma definição clara do papel do settings.json e como ele divide as tarefas com o CLAUDE.md
• Os caminhos de gravação, escopos e finalidades das três camadas de configuração: Global (User), Local de Repositório (Project) e Privada (Local)
• A tabela de precedência estruturada e o comportamento de mesclagem de vetores (uma exceção importante à regra de substituição)
• Orientações de configuração das chaves mais utilizadas: model, permissions, env, hooks e statusLine
• Um exercício prático: salvar arquivos de teste locais e validar o carregamento usando o comando /status

---

01 O que é o settings.json e como ele difere do CLAUDE.md

Conclusão direta: O settings.json gerencia chaves operacionais e comportamentais do assistente em formato JSON (permissões, variáveis de ambiente, modelos padrão, Hooks e barras de status); ele atua de forma distinta do CLAUDE.md—o primeiro parametriza a execução técnica e o segundo orienta o comportamento por meio de instruções lógicas.

É comum confundir a utilidade dos dois arquivos. As diretrizes de convenções do CLAUDE.md (Artigo 18) e as Regras de Acesso e Hooks (Artigo 20) são parametrizadas fisicamente no settings.json, mas guardam conteúdos com formatos diferentes.

Analogia: O manual do projeto vs O quadro de disjuntores. O CLAUDE.md funciona como o manual impresso na estante: detalha instruções lógicas em linguagem natural ("usar sempre pnpm", "rodar lints antes de registrar alterações") que guiam as respostas da IA. O settings.json funciona como o painel elétrico na parede: abriga chaves e chaves técnicas ("permitir ou rejeitar comando X", "modelo padrão a ser instanciado", "scripts disparados no evento Y"). O manual orienta o comportamento; o painel elétrico impõe restrições físicas de sistema.

A documentação oficial define a estrutura de configurações:

O arquivo settings.json é o mecanismo oficial para configurar o Claude Code usando configurações em camadas.

Os termos "mecanismo oficial" e "em camadas" são as chaves deste artigo: esse arquivo consolida as opções do Claude Code de forma estruturada e hierárquica (global do usuário, local do projeto e privada do diretório).

Em termos práticos, o settings.json resolve demandas como:

• "Quero bloquear comandos como rm -rf em meu terminal" — declare na chave permissions.deny
• "Desejo usar o Sonnet por padrão neste repositório para economizar tokens" — configure o parâmetro model
• "Quero formatar os códigos alterados de forma autônoma" — configure a chave hooks
• "Quero exibir o branch ativo do git no console do Claude" — customize na chave statusLine

Nenhuma dessas chaves representa instruções textuais para a IA; são diretivas de sistema que modificam a execução técnica do terminal. Essa é a distinção essencial em relação ao CLAUDE.md.

💡 Resumo em uma frase: O CLAUDE.md define orientações em linguagem natural lidas pelo modelo; o settings.json agrupa as chaves técnicas que regem o terminal—um gerencia o contexto comportamental e o outro parametriza o console.

---

02 Três camadas de configuração: Raiz, Repositório e Local

Antes de analisar os parâmetros lógicos, entenda onde salvar os arquivos no sistema de arquivos. O mesmo nome de arquivo em caminhos diferentes gerará escopos de visibilidade distintos.

Analogia: Onde colar um aviso. O recado "lembre-se de trancar as portas ao sair" surtirá efeitos diferentes se colado no portão de entrada do prédio comercial (visível a todas as empresas), na porta da sua sala de reuniões (compartilhado com sua equipe local) ou na borda do seu monitor (restrito ao seu uso pessoal). As camadas do settings.json representam esses mesmos níveis de escopo.

Escopos padrão suportados pelo Claude Code:

Camada	Caminho físico	Escopo de ação	Versionamento (Git)	Recomendações de chaves
Global (User)	~/.claude/settings.json	O seu usuário em qualquer repositório local	Não (salvo na pasta raiz do usuário)	Preferências pessoais de tema, atalhos globais e modelos padrão
Local (Project)	.claude/settings.json	Todos os colaboradores do repositório ativo	Sim (versionado no git do projeto)	Regras de segurança de equipe, lints em Hooks e conexões MCP padrão
Privada (Local)	.claude/settings.local.json	Apenas o seu usuário no repositório ativo	Não (ignorado automaticamente pelo git)	Sobrescrita de regras de segurança locais e chaves privadas de teste

Critérios de decisão simples:

• "Quero essa configuração em qualquer repositório" — use Global (User): preferências como modelo padrão ou estilizações da barra de status devem ser configuradas na raiz ~/.claude/settings.json.
• "Minha equipe deve seguir este padrão no repositório" — use Local (Project): regras de proteção e segurança que seguem o versionamento no git do projeto em .claude/settings.json.
• "Quero testar um ajuste apenas no meu terminal neste projeto" — use Privada (Local): regras restritas à sua máquina salvas em .claude/settings.local.json.

Um recurso prático de segurança nativo do Claude Code: ao detectar a criação do arquivo .claude/settings.local.json, o assistente edita as regras do git local para ignorá-lo automaticamente:

O Claude Code configurará o git para ignorar o .claude/settings.local.json quando ele for criado.

Esse isolamento impede o compartilhamento acidental de tokens privados e chaves confidenciais no repositório git. O gitignore automático impede o versionamento desse arquivo, reforçando a segurança operacional detalhada no Artigo 21.

Estrutura real de uso em produção

Exemplo de como as camadas costumam ser povoadas em um projeto real:

• Global (User): parametrização da barra de status e preferência por modelos avançados (devem seguir o desenvolvedor em qualquer repositório).
• Local (Project): lista de restrições em permissions.deny (como rejeitar o uso de curl ou ler variáveis .env) e Hooks de lints obrigatórios de versionamento (regras compartilhadas com o time).
• Privada (Local): permissões temporárias avulsas para execução rápida de comandos locais e Hooks experimentais ainda não homologados pela equipe.

Use esse fluxograma mental para decidir o destino de um parâmetro: "Esta regra é para o meu uso ou para o time?" (Meu uso = User/Local; Time = Project). Em seguida: "Essa regra deve me acompanhar em outros projetos ou é exclusiva deste diretório?" (Outros = User; Este = Local).

Evite salvar permissões exclusivas de um repositório no escopo Global (User); caso contrário, essas regras de liberação serão aplicadas indevidamente em outros diretórios locais. Mantenha os escopos separados.

💡 Resumo em uma frase: Salve em ~/.claude/settings.json para uso pessoal global, em .claude/settings.json para regras do repositório (com git) e em .claude/settings.local.json para ajustes privados locais (sem git).

---

03 Hierarquia de precedência e o comportamento de vetores

Se o mesmo parâmetro for declarado em diferentes camadas, as regras de prioridade do Claude Code definirão o valor ativo.

Ordem de precedência oficial (da mais alta para a mais baixa):

Nível	Camada/Origem	Regra de precedência
1 (Mais alto)	Managed (Gerenciado)	Políticas corporativas obrigatórias (impossíveis de contornar)
2	Flags do console	Parâmetros passados ao iniciar o console (válidos apenas na sessão ativa)
3	Privada (Local)	Configurações privadas específicas da máquina salvas no diretório local
4	Local (Project)	Configurações compartilhadas versionadas no repositório local
5 (Mais baixo)	Global (User)	Configurações padrão de usuário na pasta raiz (usadas caso não haja sobreposição)

A sobreposição de camadas funciona de cima para baixo: as definições superiores silenciam ou substituem as diretivas idênticas declaradas abaixo:

Regras temporárias ou locais próximas à execução têm precedência sobre configurações globais mais amplas, que servem apenas como comportamento padrão.

Lógica simples: regras mais específicas e imediatas têm prioridade. Flags do terminal sobrepõem regras locais de máquina, que por sua vez sobrepõem regras do repositório no git, e todas elas prevalecem sobre os padrões globais do usuário. A documentação exemplifica:

Por exemplo, se as configurações de usuário permitirem Bash(npm run *), mas as de projeto recusarem, as configurações do projeto terão prioridade e o comando será bloqueado.

Essa hierarquia permite que o time de desenvolvimento mantenha políticas de segurança consistentes no repositório, prevalecendo sobre acessos globais que você possa ter configurado em sua máquina.

A camada Managed atende a ambientes corporativos gerenciados centralizadamente por administradores de rede (via Mobile Device Management ou políticas do Windows). As diretrizes definidas nela são mandatórias e não podem ser contornadas por configurações de usuário ou de projeto. Se você atua de forma autônoma ou em times independentes, apenas saiba que ela representa o limite máximo de precedência do sistema.

A exceção crucial: vetores são mesclados, não substituídos

A regra de precedência descrita acima aplica-se a parâmetros de valor único (como a chave model). Chaves baseadas em vetores ou arrays (como permissions.allow e permissions.deny) funcionam de forma diferente: elas são unificadas entre as camadas, em vez de substituídas.

Citação da documentação:

As configurações de arrays são mescladas entre os escopos. Quando o mesmo parâmetro de array aparece em múltiplos escopos, os valores são concatenados e limpos de duplicidade, não substituídos.

Isso significa que as regras locais do projeto não apagam as permissões configuradas globalmente no usuário; ambas as regras são combinadas no terminal.

Exemplo prático:

Cenário	Suposição comum (Incorreto)	Comportamento real (Correto)
Global (User): allow: ["Bash(npm run *)"] Local (Project): allow: ["Bash(git diff *)"]	Apenas git diff * é permitido (substituição).	Ambas as chaves funcionam: npm run * e git diff * são autorizados (mesclagem).

Lembre-se da distinção entre os tipos de chaves:

• Chaves de valor único (ex: model, defaultMode): a definição superior substitui inteiramente a inferior.
• Chaves de vetores/arrays (ex: permissions.allow, permissions.deny e dados de env): os valores são concatenados e deduzidos de duplicidades.

Tenha cuidado: adicionar restrições no arquivo do projeto não substitui permissões amplas dadas nas configurações de usuário. O Claude continuará carregando os privilégios globais devido ao comportamento de concatenação.

💡 Resumo em uma frase: A prioridade segue a lógica "regras mais específicas prevalecem" (Console > Local > Project > User); contudo, chaves do tipo array (como acessos em permissions) são concatenadas e unificadas, em vez de substituídas.

---

04 Principais parâmetros do settings.json

Embora o settings.json suporte dezenas de chaves lógicas, a maior parte do trabalho de personalização envolve estes cinco campos essenciais:

Aposta-se em uma estrutura básica de arquivo sugerida para testes:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "model": "claude-sonnet-4-6",
  "permissions": {
    "allow": ["Bash(npm run test *)"],
    "deny": ["Bash(curl *)", "Read(./.env)"]
  },
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1"
  }
}

A chave $schema é altamente recomendada. Ela conecta seu JSON ao validador oficial, ativando recursos de autocompletar, preenchimento e alertas de erro em editores como o VS Code ou Cursor. Ela ajuda a evitar erros de digitação e poupa tempo. A documentação indica:

Adicione isso ao seu settings.json para habilitar o autocompletar e a validação em linha no VS Code, Cursor e qualquer outro editor compatível com validação de JSON Schema.

Detalhamento das chaves:

model: Modelo de IA padrão

Define a versão padrão do modelo de processamento do terminal (ex: "claude-sonnet-4-6").

• Onde salvar: Para padronizar preferências pessoais, salve no Global (User); para otimizar custos do repositório da equipe, adote no Local (Project).
• Atenção: Ao contrário de outras configurações dinâmicas, o campo model é lido apenas na inicialização do console. Alterações feitas no arquivo exigem reiniciar o terminal ou mudar a versão ativamente via comando /model.

Esse parâmetro permite segmentar os modelos com base no escopo do projeto: repositórios mais leves de documentações podem usar modelos mais rápidos no Local (Project), enquanto projetos principais usam o modelo padrão global mais potente configurado no User. A hierarquia local sobrepõe a global de forma automática, otimizando o consumo de tokens.

permissions: Regras de permissões e acessos

Mapeamento de acessos no terminal visto no Artigo 20, configurando as opções allow (permitido), ask (confirmar antes de rodar) ou deny (bloqueado).

• Onde salvar: Políticas de segurança obrigatórias do repositório (ex: restringir leitura de .env) devem ser salvas no Local (Project) e versionadas no git; liberações pontuais de rotinas locais podem ficar no User ou Local Privado.
• Atenção: As listas de permissions funcionam como arrays. Por serem concatenadas entre as camadas, permissões de liberação globais continuarão ativas mesmo se você tentar bloqueá-las localmente.

env: Injeção de variáveis de ambiente

Define variáveis de ambiente que serão passadas para o terminal do chat e para todos os subprocessos secundários iniciados pelo Claude.

Analogia: O crachá e ferramentas da guarita. Independentemente do operador que acessar o ambiente, todos recebem o mesmo kit básico ao entrar. O campo env atua como esse kit padrão, disponibilizando as variáveis de ambiente declaradas para qualquer comando que o assistente execute no terminal.

• Casos comuns: Habilitar ou desabilitar logs de telemetria local (CLAUDE_CODE_ENABLE_TELEMETRY) ou passar chaves de autenticação de frameworks.
• Onde salvar: Chaves e parâmetros do repositório devem ser salvos no Local (Project); configurações pessoais globais ficam no Global (User).

hooks: Automações de eventos locais

Parametrização dos scripts locais associados a eventos de ciclo de vida do terminal, que serão detalhados no Artigo 33. Permite configurar gatilhos como compilar códigos logo após edições.

• Onde salvar: Verificações de formatação padrão do time vão no Local (Project); rotinas e automatizações pessoais ficam no Global (User).
• O formato e os gatilhos lógicos dos arquivos de Hooks serão analisados no Artigo 33; por hora, saiba apenas que as referências de ativação são declaradas nesta chave.

statusLine: Personalização da barra de status

Permite customizar as informações exibidas na linha de status inferior do console do Claude Code (conforme visto no Artigo 14)—inserindo scripts para exibir branch ativo do git ou consumo de tokens.

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}

• Onde salvar: Costuma ser salvo no Global (User) de forma a manter o layout unificado do console em qualquer projeto.

Mapeamento recomendado para tomada de decisões rápida:

Parâmetro	Finalidade padrão	Camada ideal sugerida
model	Versão do modelo ativo	Global (User) ou Local (Project)
permissions	Controles de acessos	Local (Project) no git (segurança da equipe)
env	Variáveis de ambiente	Local (Project) ou Global (User)
hooks	Scripts disparados por eventos	Local (Project) ou Global (User)
statusLine	Customização do console inferior	Global (User) (preferência visual)

Distinção importante: settings.json versus .claude.json

O Claude Code mantém outro arquivo de configurações na raiz do usuário, chamado ~/.claude.json (não confunda com o ~/.claude/settings.json). Ele abriga dados da sessão ativa, tokens de autenticação, estados de confiança dos diretórios locais e registros de servidores MCP locais.

Parâmetros como autoConnectIde (conexão direta com editores) ou teammateDefaultModel (modelos padrão para integrantes de times) devem ser salvos no arquivo ~/.claude.json. Tentar configurá-los no settings.json gerará erros de validação de esquema de dados.

Lembre-se da divisão de responsabilidades: o settings.json define diretivas e comportamentos de execução do terminal, enquanto o ~/.claude.json gerencia credenciais de acesso, servidores MCP e caches internos de dados de sistema. Se encontrar erros ao tentar salvar um parâmetro, verifique se ele não pertence ao segundo arquivo.

💡 Resumo em uma frase: Os parâmetros de uso de repositório são model, permissions, env, hooks e statusLine; use o Local (Project) com git para regras de time e o Global (User) para atalhos pessoais; observe que chaves como autoConnectIde residem no arquivo ~/.claude.json.

---

05 Aplicação e validação de configurações

Explicaremos agora como editar os arquivos, os gatilhos de recarregamento e os comandos de auditoria para confirmar a leitura das configurações.

Métodos de edição: Arquivo físico ou painel /config

Você pode modificar as configurações de duas formas:

1. Edição manual direta dos arquivos JSON: abra os caminhos físicos mostrados no Passo 2 em seu editor de código. Esse formato costuma ser mais limpo e organizado.
2. Painel interativo via comando /config: acesse o editor visual no terminal do Claude Code para alternar opções comuns de visualização (como temas ou modos de verbosidade).

Atenção: o menu exibido pelo comando /config traz apenas um subconjunto de chaves visuais. Ele não mostra permissões avançadas ou caminhos de Hooks customizados; para validar todas as configurações de sistema, leia diretamente os arquivos JSON no disco.

Hot-reloading versus reinicialização obrigatória

A maioria das configurações do Claude Code possui suporte a recarregamento dinâmico (hot-reloading) em sessões de chat ativas, sem necessidade de encerrar o terminal. A documentação indica:

O Claude Code monitora seus arquivos de configuração e os recarrega quando eles mudam... Isso inclui permissions, hooks e auxiliares de credenciais.

Contudo, dois parâmetros dependem exclusivamente de reinicialização para serem aplicados (lidos uma única vez no boot):

Parâmetro	Método de aplicação ativa
model	Reiniciar o terminal ou usar o comando /model no chat
outputStyle	Reiniciar a sessão ou limpar a tela com /clear

Se modificar chaves de permissions ou hooks, a aplicação ocorrerá em tempo real. Se alterar a versão de model, feche e abra o terminal para que a IA assuma o novo processador.

Validando a indexação com o comando /status

Para conferir quais origens e arquivos físicos de configuração o Claude está lendo, execute o comando /status e localize a linha Setting sources:

A documentação detalha:

A linha Setting sources confirma quais origens estão sendo lidas... Uma camada só aparece na lista se pelo menos uma chave for carregada a partir dela; assim, uma lista vazia significa que nenhuma origem de configuração foi encontrada.

Regras de diagnóstico:

• Camada listada: O arquivo correspondente foi localizado e lido com sucesso.
• Camada ausente: O arquivo foi ignorado (provavelmente devido a caminhos físicos incorretos, como salvar o arquivo na raiz do projeto sem a pasta .claude).
• Erro de formatação: Se houver falhas de sintaxe (como JSON quebrado), o console exibirá um alerta indicando a linha com erro.

Crie o hábito de rodar /status após salvar alterações no settings.json para validar a indexação imediata do arquivo.

Guia de resolução de problemas

Se as chaves de configuração falharem no terminal, verifique estes tópicos estruturais:

Sintoma no console	❌ Evite focar em	✅ Verifique primeiro
Alterações ignoradas no console	Erros de digitação de parâmetros	Verifique se a origem consta em Setting sources via /status (valide se a pasta .claude/ existe).
Modelo padrão inalterado	Sintaxe do arquivo de regras	Reinicie o terminal do Claude (a chave model exige boot para recarregamento).
Chave defaultMode inativa	Erros de escrita no JSON	Valide se salvou no User (~/.claude/); o modo auto é rejeitado em escopos de projeto.
Comando rodando mesmo com deny	Sintaxe do bloqueio da chave	Valide as regras de permissions de outras camadas; permissões globais allow persistem devido à concatenação de arrays.
Parâmetro rejeitado no settings.json	Erros de escrita de colunas	Verifique se a chave técnica não pertence ao arquivo central ~/.claude.json (como a chave autoConnectIde).

Isso indica que a maior parte das inconsistências deve-se a conflitos de camadas, concorrência de vetores ou gatilhos de boot, e não a falhas de código JSON.

💡 Resumo em uma frase: Modifique via JSON ou use /config para opções visuais; lembre-se de que permissions recarrega dinamicamente, enquanto model exige reinicialização; valide a leitura dos caminhos físicos conferindo o comando /status.

---

06 Exercício prático: Configurando escopos em camadas

Vamos testar o fluxo prático: criar os arquivos de projeto e máquina → simular ignorar pelo git → verificar leitura dinâmica → auditar a unificação das permissões.

Passo 1: Criar a pasta do repositório de teste (PowerShell)

New-Item -ItemType Directory -Path "settings-demo" -Force
cd settings-demo

Passo 2: Salvar o arquivo de configuração local do projeto

Crie a subpasta .claude e salve o arquivo .claude/settings.json com as seguintes regras de segurança, utilizando $schema para habilitar a validação do editor:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": ["Bash(npm run test *)"],
    "deny": ["Bash(curl *)"]
  }
}

Passo 3: Salvar a regra local privada de máquina

Crie o arquivo .claude/settings.local.json com permissões de execuções pontuais de desenvolvimento:

{
  "permissions": {
    "allow": ["Bash(git status *)"]
  }
}

Saída esperada: O diretório .claude/ contará com os dois arquivos de escopo criados. A política privada local deve ser ignorada automaticamente pelo git.

Passo 5: Confirmar a exclusão automática no controle de versão

git init
git status --short

Saída esperada: O console listará apenas o .claude/settings.json como arquivo pendente de commit. O arquivo privado .claude/settings.local.json foi omitido pelo versionador, validando a regra de isolamento automático.

Passo 5: Inicializar o chat e inspecionar a leitura com /status

claude

No terminal do chat, execute:

/status

Saída esperada: O painel exibirá as origens ativas em Setting sources, indicando a leitura bem-sucedida do escopo do projeto e do escopo privado de máquina. Se alguma camada estiver ausente, revise o nome e o caminho físico das pastas.

Passo 6: Conferir a unificação de regras de acesso

/permissions

Saída esperada: A listagem unificará as chaves: npm run test * e git status * estarão na seção de permitidos, enquanto curl * estará nos bloqueados. Isso comprova que as listas de acessos de camadas distintas foram concatenadas, e não sobrepostas.

Esse ciclo conclui a validação de configurações em camadas do Claude Code. Você pode seguir a mesma rotina para mapear e testar qualquer outra propriedade técnica.

---

07 Resumo

Revisão dos pontos principais:

Dúvida comum	Resposta	Ponto-chave a lembrar
Diferença do CLAUDE.md	Papéis distintos	O CLAUDE.md orienta o modelo; o settings.json gerencia o terminal técnico.
Camadas e caminhos	Três níveis padrão	Global (User), Local (Project, no git) e Privada (Local, sem git).
Hierarquia de precedência	Regras mais específicas	Console > Local > Project > User (Managed na raiz).
Comportamento de arrays	Concatenação de itens	Parâmetros de listas (como acessos) são mesclados, não substituídos.
Parâmetros de uso	Cinco chaves principais	Modelos (model), acessos (permissions), ambientes (env), Hooks e visualizações.
Validação de carregamento	Comando /status	A linha Setting sources confirma a leitura física correta do JSON.

Agora você deve ser capaz de: Organizar configurações entre chaves globais e locais de projeto, gerenciar a priorização de segurança das chaves do terminal, usar $schema para validar e autocompletar chaves do JSON e diagnosticar leituras usando o comando /status. Essas chaves lógicas alinham o assistente às regras de governança de sua equipe.

---

No próximo artigo, 32 "Estilos de Exibição (Output Styles)"—analisaremos a chave outputStyle do settings.json. Veremos como esse parâmetro modifica o estilo de resposta e o tom das explicações do Claude (alternando de assistente de codificação direto para tutor acadêmico ou revisor conciso). Descubra as diferenças de comportamento de estilo no console a seguir.

---

Leitura Recomendada

• Uso e persistência do sistema de Memória permanente
• Empacotamento e distribuição de atalhos locais com Plugins
• Conceitos básicos de terminal e comandos do Claude Code