Eu já vi isso acontecer em pelo menos 40 software houses que eu mentoro.
O CEO investe em Claude Code. Time fica animado. Produtividade sobe. Aí o TI liga o Zscaler — ou o CrowdStrike Falcon, ou o Netskope, tanto faz — e no dia seguinte, metade do time não consegue mais usar a ferramenta.
O erro? UNABLE_TO_GET_ISSUER_CERT_LOCALLY. Ou self-signed certificate in certificate chain. Ou simplesmente “connection failed” sem explicação.
E começa a novela: dev abre ticket pro TI. TI demora 3 dias. Dev descobre um hack no Stack Overflow (NODE_EXTRA_CA_CERTS=/path/to/cert.pem). Outro dev faz SSL_VERIFY=false — que é basicamente desligar a segurança. Um terceiro dev simplesmente para de usar Claude Code e volta pro jeito antigo.
A Anthropic resolveu isso na v2.1.101 com uma mudança que deveria ter existido desde o dia zero.
O Que Mudou: OS CA Certificate Store Trust
A partir da versão 2.1.101 do Claude Code, lançada em 10 de abril de 2026, o Claude Code confia automaticamente nos certificados do sistema operacional além dos certificados Mozilla que já vêm empacotados.
Na prática, isso significa: se o seu proxy corporativo (Zscaler, CrowdStrike Falcon, Netskope, Palo Alto, Forcepoint — qualquer um) instalou um certificado raiz no trust store do sistema operacional, o Claude Code vai confiar nele automaticamente. Sem configuração. Sem variável de ambiente. Sem ticket pro TI.
A variável de controle é CLAUDE_CODE_CERT_STORE, que aceita uma lista separada por vírgula:
bundled— apenas os certificados Mozilla empacotados no Claude Codesystem— apenas o certificate store do sistema operacionalbundled,system— ambos (padrão desde v2.1.101)
# Padrão — funciona com proxy corporativo automaticamente
# Não precisa fazer NADA. Já é o default.
# Se por algum motivo quiser desabilitar o trust do OS:
export CLAUDE_CODE_CERT_STORE=bundled
# Se quiser confiar APENAS no OS (ignora Mozilla CAs):
export CLAUDE_CODE_CERT_STORE=systemPara ambientes que exigem autenticação mútua TLS (mTLS) — comum em bancos e empresas reguladas — o Claude Code também suporta:
export CLAUDE_CODE_CLIENT_CERT=/path/to/client-cert.pem
export CLAUDE_CODE_CLIENT_KEY=/path/to/client-key.pem
export CLAUDE_CODE_CLIENT_KEY_PASSPHRASE="sua-passphrase"Documentação oficial: Enterprise Network Configuration
Por Que Isso É Maior Do Que Parece
Você pode estar pensando: “Ok, confia no certificado do OS. E daí?”
E daí que 93% das empresas hoje usam encriptação em trânsito (SSL/TLS, VPNs). E daí que mais de 4.400 empresas usam Zscaler só como proxy de rede — a maioria com 10.000+ funcionários. E daí que a tendência é de mais inspeção TLS, não menos: 71% do malware atual chega via conexões encriptadas, segundo o WatchGuard Internet Security Report Q1 2025. As empresas estão obrigadas a inspecionar tráfego SSL se quiserem se proteger.
Ou seja: proxy com TLS inspection não é exceção. É regra. E vai ser cada vez mais.
O problema é que ferramentas de desenvolvimento historicamente não lidam bem com isso. O Node.js — runtime em que o Claude Code roda — só adicionou NODE_USE_SYSTEM_CA=1 na versão 22.15.0, em abril de 2025. Antes disso, a única opção era NODE_EXTRA_CA_CERTS, que nem sempre funciona em post-install scripts. E NODE_TLS_REJECT_UNAUTHORIZED=0? Desliga a verificação inteira. É como resolver o alarme da casa cortando o fio.
A Anthropic tomou a decisão correta: confiar no OS trust store por padrão. Não como flag experimental. Não como documentação escondida. Como comportamento padrão.
O Custo Real de Um Certificado Não Confiável
Vamos aos números que eu gosto de mostrar pros CEOs das SHs que eu mentoro.
Tempo perdido por outage de certificado: Uma pesquisa da Resilience Forward mostrou que a remediação de um incidente relacionado a certificado leva no mínimo 5 horas. Mais da metade dos entrevistados relatou downtimes de 5 a 24 horas. E 15,4% passou de 25 horas.
Impacto financeiro direto: 31% das organizações perderam entre US$50.000 e US$250.000 com problemas de certificado. 18,5% perderam mais de US$250.000.
E isso é para certificados em produção. Agora imagina o custo invisível: aquele dev que perde 2 horas tentando fazer Claude Code funcionar atrás do proxy. Que abre ticket. Que espera. Que tenta workaround. Que frustra. Que volta pro Copilot (que talvez funcione, talvez não). Multiplica por 20 devs. Por 50 dias úteis no trimestre.
Eu já vi SH perder R$30.000+ por trimestre em produtividade desperdiçada porque a ferramenta de IA não conversava com o proxy corporativo.
O Que Era Antes vs. O Que É Agora
Antes da v2.1.101:
# O dev tinha que descobrir onde o TI guardou o certificado raiz
export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/corporate-ca.pem
# Ou pior: desligava a verificação inteira
export NODE_TLS_REJECT_UNAUTHORIZED=0
# Ou ainda pior: cada dev fazia diferente
# Dev 1: NODE_EXTRA_CA_CERTS no .bashrc
# Dev 2: SSL_VERIFY=false no .zshrc
# Dev 3: abriu exceção no Zscaler só pro Claude Code
# Dev 4: desistiu e voltou pro método antigoDepois da v2.1.101:
# Nada. Zero config. Funciona.
claudeIsso é o que eu chamo de friction engineering resolvido. A Anthropic entendeu que se a ferramenta não funciona no ambiente real do desenvolvedor — com proxy, com VPN, com compliance, com TI controlando tudo — ela simplesmente não vai ser usada.
O Contexto Que Torna Isso Urgente
Três coisas estão acontecendo ao mesmo tempo em 2026:
1. Certificados estão ficando mais curtos. O CA/Browser Forum votou pela redução gradual: 200 dias máximo desde março de 2026, 100 dias em março de 2027, e 47 dias em março de 2029. Mais rotação = mais chances de quebra = mais importância de confiar no trust store correto.
2. TLS inspection está virando obrigação. Com 71% do malware viajando encriptado e regulações como LGPD e EU AI Act exigindo visibilidade sobre dados em trânsito, empresas que NÃO inspecionam SSL estão ficando expostas — legal e tecnicamente.
3. AI coding tools estão virando infraestrutura. 73% dos times de engenharia usam ferramentas de AI coding diariamente (Pragmatic Engineer Survey, fev/2026). Claude Code é a mais amada, com 46% de preferência entre 15.000 devs. Quando a ferramenta mais usada do time não funciona no proxy, o custo não é inconveniência — é parada de produção.
Como Configurar na Sua Software House
Se você usa proxy corporativo com TLS inspection:
Boa notícia: não precisa fazer nada. Desde que o certificado raiz do proxy esteja instalado no trust store do sistema operacional (o que o TI já faz como parte da configuração do proxy), o Claude Code v2.1.101+ vai confiar nele automaticamente.
Se você precisa de mTLS (bancos, fintechs, empresas reguladas):
# No settings.json do Claude Code (~/.claude/settings.json):
{
"env": {
"CLAUDE_CODE_CLIENT_CERT": "/path/to/client-cert.pem",
"CLAUDE_CODE_CLIENT_KEY": "/path/to/client-key.pem"
}
}Se você quer forçar apenas certificados bundled (rollback):
export CLAUDE_CODE_CERT_STORE=bundledSe você quer validar que está funcionando:
claude --version # Deve ser 2.1.101 ou superior
claude # Se conectar sem erro, o trust store está funcionandoPara deployments em larga escala (managed settings):
Administradores podem definir via managed settings distribuídas por MDM (Jamf, Intune, GPO), garantindo configuração uniforme em todo o time.
O Ecossistema Enterprise do Claude Code
Essa mudança não é isolada. Ela faz parte de uma série de melhorias enterprise que a Anthropic vem entregando:
- PID Namespace Isolation + SCRIPT_CAPS (v2.1.98) — Sandbox com namespace de processos isolado
- OTEL Observability (v2.1.97) — Traces distribuídos e métricas para monitorar custo e uso
- Amazon Bedrock Mantle (v2.1.94) — Data residency e billing via AWS
- Interactive Vertex AI Setup Wizard (v2.1.98) — Setup guiado para Google Cloud
- OS CA Certificate Store Trust (v2.1.101) — Proxy corporativo funciona out of the box
Juntas, essas features respondem às 5 objeções clássicas de um CTO para não adotar AI coding tools: segurança, observabilidade, data residency, custo e compatibilidade com a infra existente.
O Que Eu Penso
Na minha experiência com 300+ software houses, o proxy corporativo é o assassino silencioso da adoção de IA.
Ninguém fala sobre isso nas conferências. Ninguém tuíta sobre UNABLE_TO_GET_ISSUER_CERT_LOCALLY. Mas eu sei que em pelo menos 30% das SHs que eu mentoro, algum dev teve esse problema na primeira semana de uso do Claude Code.
A Anthropic fez o certo: não criou mais uma flag. Não documentou um workaround. Mudou o comportamento padrão para funcionar no mundo real. Isso é maturidade de produto. Isso é pensar em enterprise de verdade.
Se você tem proxy corporativo e ainda não atualizou para a v2.1.101, faça isso hoje. Se você está avaliando Claude Code para o seu time e tinha receio de compatibilidade com a infra — essa objeção não existe mais.
E se você quer implementar Claude Code na sua software house com proxy, sandbox, observabilidade e tudo que uma operação enterprise precisa — é exatamente isso que eu ajudo a montar.
Sou Thulio, mentoro 300+ SHs desde 2016.
Quer levar sua software house para o próximo nível com IA? Conheça a Imersão Software House 10x — o evento presencial exclusivo para empresas de software que querem crescer com inteligência.
Referências:
- Changelog Claude Code v2.1.101
- Enterprise Network Configuration
- SSL Insights — SSL Certificates Statistics
- Resilience Forward — Certificate Management Failures Survey
- Zscaler — SSL Inspection in Developer Environments
- Pragmatic Engineer — AI Tooling Survey 2026
- Node.js Issue #51537 — NODE_EXTRA_CA_CERTS limitations
- Claude Code Issue #24470 — OS CA Certificate Store
