Semana passada eu tava numa call com o CTO de uma software house de 40 devs. Ele me mostrou orgulhoso o painel de managed settings do Claude Code: deny rules pra curl, bloqueio de .env, hooks de auditoria, permissões centralizadas. Tudo bonito.
Aí eu perguntei: “E quando o dev novo entra na segunda-feira, abre o Claude Code pela primeira vez, e o cache de settings ainda não existe… o que acontece?”
Silêncio.
“E quando a rede do escritório cai por 30 segundos durante o startup?”
Mais silêncio.
A verdade é que 82% dos executivos de tech dizem que suas políticas protegem contra ações não autorizadas de agentes de IA — mas apenas 14,4% realmente mandam agentes pra produção com aprovação completa de segurança. Na minha experiência com 300+ software houses, a governança de IA é como alarme de carro: todo mundo tem, quase ninguém sabe se funciona.
Até agora, o Claude Code tinha uma janela. Pequena, mas real. E na v2.1.92, a Anthropic fechou essa janela com uma setting chamada forceRemoteSettingsRefresh.
O Gap que Ninguém Percebeu
Vamos ao cenário real. Você é dono de uma SH com 20 devs. Configurou as managed settings do Claude Code no painel do Claude.ai:
- Deny rules pra
curl *,Read(.env),Read(./secrets/) allowManagedPermissionRulesOnlyativado- Hooks de auditoria em cada
EditeWrite disableBypassPermissionsModehabilitado
Perfeito. Seguro. Compliant.
Só que a documentação oficial sempre teve esse parágrafo na seção “Fetch and caching behavior”:
First launch without cached settings: Claude Code fetches settings asynchronously. If the fetch fails, Claude Code continues without managed settings. There is a brief window before settings load where restrictions are not yet enforced.
Leu direito? “There is a brief window where restrictions are not yet enforced.” Em português: existe uma janela onde suas restrições simplesmente não existem.
E não é só no primeiro launch. A tabela de segurança da documentação lista explicitamente:
| Cenário | Comportamento |
|---|---|
| Dev deleta o cache de settings | First-launch behavior: janela sem enforcement |
| API indisponível | Cache aplica se existir, senão managed settings não são enforced |
| Dev troca ANTHROPIC_BASE_URL | Server-managed settings são bypassed |
Três cenários reais onde sua governança simplesmente não existe. E o pior: você nem fica sabendo.
O Que É forceRemoteSettingsRefresh
Na v2.1.92, lançada hoje (04/04/2026), a Anthropic adicionou uma policy setting chamada forceRemoteSettingsRefresh. O comportamento é simples e brutal:
- O CLI bloqueia o startup até fazer um fetch bem-sucedido das managed settings remotas
- Se o fetch falhar, o CLI não inicia — ele encerra
Isso é o que em segurança chamamos de fail-closed: na dúvida, fecha. O oposto do comportamento anterior (fail-open): na dúvida, abre.
A diferença conceitual é enorme. Fail-open assume que o cen��rio padrão é “permitir”. Fail-closed assume que o cenário padrão é “negar”. Toda a literatura de segurança de 2026 converge pra essa conclusão: ferramentas de IA que operam em fail-open são um vetor de ataque.
E forceRemoteSettingsRefresh é uma policy setting — o que significa que só o admin configura. O dev não pode desligar. Não aparece no settings.json do usuário. Não tem flag de CLI que override. É governance de verdade.
Como Configurar
Você configura no painel do Claude.ai, na mesma tela onde já configura suas managed settings:
Admin Settings > Claude Code > Managed settings:**
{
"forceRemoteSettingsRefresh": true,
"permissions": {
"deny": [
"Bash(curl )",
"Read(./.env)",
"Read(./.env.)",
"Read(./secrets/)"
],
"disableBypassPermissionsMode": "disable"
},
"allowManagedPermissionRulesOnly": true
}Uma linha. "forceRemoteSettingsRefresh": true. É isso.
A partir desse momento, todo dev da sua organização que abrir o Claude Code vai:
- Ver o CLI aguardando o fetch das settings
- Só conseguir usar a ferramenta após as settings serem aplicadas
- Ser impedido de usar se a rede estiver fora ou o fetch falhar
Zero janela. Zero bypass. Zero “ah mas eu não sabia que as settings não tinham carregado.”
Por Que Isso Importa para Sua Software House
Vou te dar o contexto macro. Os números de 2026 são assustadores.
O gap entre adoção e governança é absurdo. 88% das organizações usam IA em pelo menos uma função de negócio, mas quase dois terços ainda estão em fase de experimentação ou piloto. 75% reportam ter processo dedicado de governança de IA — mas apenas 12% descrevem seus esforços como maduros.
AI agents operam com permissões excessivas. 63% das organizações não conseguem tecnicamente enforçar limitações de propósito em seus agentes. A maioria dos agentes herda permissões amplas dos sistemas que conectam, sem zero-trust boundaries governando o que realmente podem acessar.
O custo de não governar é real. Shadow AI adiciona $670.000 ao custo médio de um breach. E a EU AI Act entra em enforcement em agosto de 2026, com multas de até 35 milhões de euros.
Agora pensa na sua SH. Você tem 20 devs usando Claude Code. Cada dev executa dezenas de tool calls por sessão: Bash commands, file reads, file writes, MCP calls. Se as managed settings não carregaram — por 5 segundos, por 30 segundos, por uma sessão inteira — cada uma dessas calls é uma call sem governança.
Na minha experiência, o problema não é o dev malicioso. É o dev desavisado. É a segunda-feira depois do feriado quando a VPN demora pra conectar. É o freelancer no café com wifi instável. É o notebook novo que ainda não tem cache. São cenários mundanos que acontecem toda semana.
O Stack Completo de Governança (Atualizado)
Se você acompanha esta série, já conhece as peças do quebra-cabeça. Com forceRemoteSettingsRefresh, o stack agora tem 6 camadas:
| Camada | Feature | O que resolve |
|---|---|---|
| 1. Delivery | forceRemoteSettingsRefresh |
Garante que settings remotas carreguem ANTES do CLI iniciar |
| 2. Policy fragments | managed-settings.d/ |
Compõe políticas por squad/equipe via drop-in directory |
| 3. Permissões | allowManagedPermissionRulesOnly + deny rules |
Restringe o que o agente pode fazer |
| 4. Hooks | PreToolUse/PostToolUse + HTTP hooks | Auditoria e enforcement runtime |
| 5. Observabilidade | X-Claude-Code-Session-Id + OTel |
Rastreia quem faz o quê, quanto custa |
| 6. Modelos | modelOverrides + availableModels |
Controla quais modelos cada dev acessa |
A camada 1 é a fundação. Sem ela, as camadas 2-6 podem não estar ativas quando o dev começa a trabalhar. É como instalar 5 fechaduras numa porta que às vezes fica entreaberta.
Fail-Closed vs Fail-Open na Prática
Deixa eu ser direto. O comportamento fail-open anterior tinha uma lógica: não travar o dev. Se a rede caiu, deixa ele trabalhar. As settings carregam depois.
E pra muitas SHs, isso é OK. Se você tem 3 devs que você confia e não tem requisitos de compliance, fail-open é pragmático.
Mas se você tem 20+ devs, freelancers rotativos, clientes enterprise com requisitos de auditoria, ou opera em setores regulados — fail-open é um risco documentado.
A pergunta não é “vai acontecer um breach?”. A pergunta é: “quando o auditor perguntar se TODAS as sessões do Claude Code rodaram com as policies ativas, você vai poder dizer sim?”
Com fail-open: não. Com forceRemoteSettingsRefresh: sim.
Também na v2.1.92: Bedrock Setup Wizard e /cost com Breakdown por Modelo
Duas outras features dessa versão merecem menção:
Interactive Bedrock Setup Wizard — Se sua SH usa AWS, a tela de login agora tem um wizard que guia a configuração do Bedrock: autenticação AWS, região, verificação de credenciais, model pinning. Antes era tudo manual via variáveis de ambiente. Agora é passo a passo.
Per-model e cache-hit breakdown no /cost** — Assinantes agora veem exatamente quanto cada modelo (Opus, Sonnet, Haiku) consumiu, e quanto o prompt caching economizou. Cache reads custam 10% do preço base — uma economia de até 90% que antes era invisível. Se você gerencia custo de IA com seriedade, /cost agora é um raio-X, não mais uma conta total.
O Que Eu Penso
Essa feature é daquelas que parece pequena mas muda a conversa. Antes de forceRemoteSettingsRefresh, managed settings do Claude Code eram uma sugestão forte. Agora são um enforcement real.
80% das empresas Fortune 500 já usam AI agents ativos. A maioria não consegue parar esses agentes quando algo dá errado. A diferença entre “temos governance” e “governance está ativa em 100% das sessões” é exatamente o que forceRemoteSettingsRefresh resolve.
Se você tá escalando sua SH de 5 pra 20+ devs com Claude Code, ativa essa setting hoje. Uma linha de JSON. Fail-closed. Sem janela. Sem desculpa.
Conclusão
Governança de IA não é sobre ter policies no painel. É sobre garantir que essas policies estejam ativas em CADA sessão, em CADA máquina, em CADA startup. forceRemoteSettingsRefresh transforma managed settings de “best effort delivery” em “guaranteed delivery or no CLI.”
Se você quer implementar esse nível de governança de IA na sua software house, começa pelo stack completo: forceRemoteSettingsRefresh na camada 1, managed-settings.d/ na camada 2, deny rules na 3, hooks na 4, OTel na 5, e modelOverrides na 6. Cada camada que você adiciona é um risco a menos que seu cliente enterprise descobre numa auditoria.
Sou Thulio, mentoro 300+ SHs desde 2016.
Leia também:
