O Claude Code 2.1.92 adicionou uma configuração com consequência incomum para uma ferramenta de desenvolvimento: forceRemoteSettingsRefresh pode impedir que a CLI abra quando não consegue buscar as políticas remotas da organização. Sem atualização, a sessão termina. Não há continuidade com regras antigas em cache nem modo degradado para o usuário decidir depois.
Esse comportamento troca disponibilidade local por certeza de política. A escolha faz sentido em ambientes onde o risco de um agente operar com permissões obsoletas supera o custo de interromper o trabalho. Também deixa claro que distribuir um agente para uma empresa exige controles diferentes daqueles de uma instalação individual.
A mesma versão trouxe disableSkillShellExecution, que bloqueia comandos de shell disparados por skills e plugins, além de ampliar para 500 mil caracteres a persistência de resultados MCP. As três mudanças lidam com a mesma tensão: agentes precisam de contexto e ferramentas para serem úteis, mas cada capacidade amplia a superfície que uma organização deve governar.
Fail-closed é uma decisão operacional
Sistemas fail-open continuam funcionando quando o mecanismo de controle falha. Isso preserva disponibilidade, porém aceita um período em que a política aplicada pode estar desatualizada. Sistemas fail-closed bloqueiam a operação até confirmar as regras. A segurança aumenta, acompanhada de uma dependência nova: o serviço que entrega a configuração passa a fazer parte do caminho crítico.
Ativar essa opção sem preparar a operação apenas desloca o incidente. Uma falha de rede, DNS, autenticação ou disponibilidade do endpoint pode parar dezenas de engenheiros ao mesmo tempo. O time precisa monitorar o serviço de configuração, definir objetivos de disponibilidade e saber distinguir um bloqueio legítimo de uma pane no plano de controle.
Também é necessário planejar o primeiro acesso. Máquinas novas, runners efêmeros e sandboxes começam sem estado confiável. Se a política remota é obrigatória, autenticação e conectividade precisam existir antes da abertura do agente. A documentação de onboarding deve tratar isso como requisito, não como troubleshooting posterior.
Bloquear shell em skills reduz confiança transitiva
Uma skill pode parecer um arquivo de instruções e ainda carregar execução de comandos. Plugins podem combinar orientações, scripts e integrações externas. Quando um engenheiro instala esse pacote, a organização herda a confiança depositada no autor, no repositório, no mecanismo de atualização e em qualquer dependência usada pelo script.
disableSkillShellExecution oferece uma fronteira central. O agente continua lendo instruções, enquanto a parte capaz de executar no sistema recebe uma restrição explícita. Isso é útil quando a empresa quer permitir extensões para padrões de código e documentação sem autorizar automaticamente ações locais.
O controle não elimina todo o risco. Uma instrução maliciosa pode tentar induzir o próprio agente a usar outra ferramenta autorizada. Permissões de arquivos, rede, secrets e comandos continuam necessárias. A opção reduz uma rota de execução e torna a revisão mais simples, mas não substitui sandbox ou allowlist.
Mais contexto persistido também pede limites
Elevar a persistência de resultados MCP para 500 mil caracteres evita truncar schemas, dumps de configuração e consultas extensas. Um agente consegue consultar o material em etapas posteriores sem refazer a chamada. Para investigação técnica, isso reduz repetição e preserva evidência.
O ganho vem com duas perguntas. A primeira é se o resultado contém segredo, dado pessoal ou informação de outro ambiente. Persistência amplia a duração e os lugares onde esse conteúdo pode aparecer. A segunda é se o volume realmente ajuda. Meio milhão de caracteres irrelevantes pode prejudicar a seleção de contexto e aumentar custo.
Servidores MCP deveriam devolver apenas os campos necessários, paginar coleções grandes e marcar conteúdo sensível. Aumentar o teto resolve truncamento; não dispensa um contrato de resposta adequado.
Uma implantação corporativa mínima
Antes de obrigar a atualização remota, a organização pode executar um piloto com um grupo pequeno. O teste inclui perda de conexão, credencial expirada, endpoint indisponível e política inválida. Cada cenário deve produzir uma mensagem que permita ao suporte identificar a causa sem pedir ao usuário que desative o controle.
Depois, vale separar políticas universais das específicas por repositório. Restrições de secrets e execução podem ser globais. Comandos de build e caminhos permitidos pertencem mais perto do projeto. Uma configuração central gigantesca fica difícil de revisar e pode bloquear casos legítimos sem explicar por quê.
Por fim, logs precisam registrar a versão da política aplicada, o horário da última atualização e o motivo do bloqueio. Governança que só impede a sessão gera chamados; governança observável permite auditoria.
O modo fail-closed é um sinal de maturidade do produto e uma obrigação para quem o ativa. A empresa ganha a capacidade de afirmar que nenhuma sessão começou fora das regras atuais. Em troca, precisa operar a distribuição dessas regras como parte da infraestrutura de engenharia, com responsáveis, alertas e recuperação definidos antes da adoção geral.
