Claude Code UNABLE_TO_GET_ISSUER_CERT: como resolver

Você atualizou o Claude Code, abriu a sessão e toda requisição passou a morrer com SSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT). O CA da empresa está configurado, nada mudou na rede, e a mesma máquina funcionava ontem. Se esse é o seu caso, o problema provavelmente não é a sua configuração: é a versão 2.1.304.

Qual é a mensagem de erro completa?

Ela aparece logo na primeira requisição, sem novas tentativas, porque o Claude Code não repete falha de certificado desde a v2.1.199:

API Error: Unable to connect to API: SSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT). The certificate comes from an authority Claude Code doesn't trust, usually a TLS-inspecting corporate proxy or a gateway signed by a private CA: set NODE_EXTRA_CA_CERTS to that CA bundle, or add it to the system certificate store

A própria mensagem manda configurar NODE_EXTRA_CA_CERTS. Isso resolve quando o CA nunca foi configurado. Não resolve quando ele já está configurado e a versão nova deixou de usá-lo, que é o que a issue #103680 do repositório oficial descreve desde 20 de outubro de 2026.

É a minha configuração ou é a versão?

Se funcionava na 2.1.303 e quebrou depois de atualizar, sem você mudar nada, é a versão. Se nunca funcionou nessa máquina, é configuração. A tabela separa os casos:

Sintoma	Causa provável	O que fazer
Máquina nova ou CA nunca configurado; o log não mostra o CA carregado	Configuração	Apontar `NODE_EXTRA_CA_CERTS` para o bundle do CA
Funcionava até a 2.1.303; o log mostra o CA carregado e a conexão falha mesmo assim	Regressão da 2.1.304 (issue #103680)	Voltar para a 2.1.303 e travar o auto-update
Erro só num servidor MCP HTTP com cadeia emSign, código `CERT_REJECTED` nas versões mais novas	Lista de bloqueio de certificados nova da 2.1.304, segundo relatos	Sem contorno confirmado; acompanhar a issue

Fluxograma do erro UNABLE_TO_GET_ISSUER_CERT no Claude Code: confirmar no claude --debug que o CA carregou, voltar para a 2.1.303 com o instalador oficial e travar com DISABLE_AUTOUPDATER=1; se o CA não aparece no log, configurar NODE_EXTRA_CA_CERTS — Do erro ao contorno em 4 passos. Fontes: issue #103680 (anthropics/claude-code), CHANGELOG e documentação oficial, conferidos em 24/10/2026.

Como confirmar que o Claude Code carregou o meu CA?

Rode uma sessão com log de depuração e procure as linhas que começam com CA certs:. Se o CA aparece ali e a conexão falha mesmo assim, você está na regressão.

claude --version
claude --debug

O log não vai para o terminal: ele fica em ~/.claude/debug/<session-id>.txt (ou no caminho que você passar com --debug-file). Num terminal Linux ou macOS:

grep "CA certs" ~/.claude/debug/*.txt | tail -n 20

Este é o trecho que o autor da #103680 publicou na 2.1.304, com o CA carregado e a conexão falhando logo depois:

CA certs: stores=bundled,system, extraCertsPath=C:/.../gateway-ca.pem
CA certs: Loaded 117 bundled root certificates
CA certs: Loaded 123 system CA certificates
CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS
[ERROR] Bedrock ListInferenceProfiles failed: unable to get issuer certificate

Se a linha Appended extra certificates from NODE_EXTRA_CA_CERTS não aparece, o Claude Code não leu o seu arquivo. Aí o problema é configuração, e a próxima seção não se aplica.

O CA não aparece no log: como configurar do jeito certo?

Coloque a variável no bloco env do ~/.claude/settings.json, não só no shell. A documentação oficial explica o motivo: agentes em segundo plano rodam num processo supervisor que herda o ambiente de qualquer terminal que o iniciou primeiro, e só o settings chega a todas as sessões.

{
  "env": {
    "NODE_EXTRA_CA_CERTS": "/caminho/para/ca-bundle.pem",
    "CLAUDE_CODE_CERT_STORE": "bundled,system"
  }
}

bundled,system já é o padrão: o Claude Code confia no conjunto da Mozilla que vem embutido e no repositório de certificados do sistema operacional. Deixe explícito só se alguém mudou isso antes. O bundle precisa estar em PEM e, num gateway com CA privado, conter a raiz e os intermediários.

Como voltar para a 2.1.303 e travar a versão?

Use o instalador oficial passando o número da versão e depois desligue o auto-update. Sem a segunda parte, o Claude Code volta sozinho para a versão quebrada na próxima checagem.

macOS, Linux e WSL:

curl -fsSL https://claude.ai/install.sh | bash -s 2.1.303

Windows PowerShell:

& ([scriptblock]::Create((irm https://claude.ai/install.ps1))) 2.1.303

Confira:

claude --version
# 2.1.303 (Claude Code)

Agora trave o auto-update no ~/.claude/settings.json:

{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  }
}

E confirme que pegou:

claude doctor
# Auto-updates: disabled (set by env: DISABLE_AUTOUPDATER)

Três detalhes que a documentação deixa claros:

DISABLE_AUTOUPDATER só desliga a checagem em segundo plano. claude update e claude install manuais continuam funcionando, então ninguém do time deve rodar claude update por reflexo enquanto a trava estiver ativa.
Instalação via Homebrew ou WinGet não se atualiza sozinha. Se você instalou por eles e ainda está na 2.1.303 ou anterior, basta não rodar o upgrade.
Quem prefere menos risco no longo prazo pode usar "autoUpdatesChannel": "stable", que fica cerca de uma semana atrás e pula versões com regressão grave. Não é garantia para este bug específico: confira a versão depois de trocar.

Por que não usar NODE_TLS_REJECT_UNAUTHORIZED=0?

Porque desliga a validação de certificado inteira, para todo host. A página oficial de erros do Claude Code diz isso com todas as letras. Você troca um erro visível por uma conexão que aceita qualquer certificado, inclusive o de quem estiver no meio do caminho. Voltar uma versão é reversível; abrir o TLS não é algo que você percebe depois.

Já saiu correção?

Até 24 de outubro de 2026, não. O CHANGELOG oficial vai até a 2.1.310 sem nenhuma entrada sobre CA customizado em conexões Bedrock ou gateway. Na issue, um usuário confirmou que o erro continua na 2.1.306 e outro postou log da 2.1.307 com o mesmo problema.

Para saber a hora de tirar a trava, acompanhe a #103680 e o CHANGELOG. Quando a correção sair, apague a linha DISABLE_AUTOUPDATER e rode:

claude update
claude --debug

Teste uma requisição real antes de liberar para o time. Ficar parado na 2.1.303 também tem custo: a 2.1.309, por exemplo, trouxe várias correções de sandbox e de checagem de permissão do Bash. A trava é para atravessar o bug, não para morar nela.

E se o erro aparece num servidor MCP HTTP?

Pode ser outra causa. Na mesma issue, um usuário mostrou um servidor MCP "type": "http" cuja cadeia passa pela raiz emSign Root CA - G1 e que parou de conectar na 2.1.304. No log da 2.1.307 aparecem a linha Dropped blocked certificate e o código CERT_REJECTED, e o número de raízes embutidas caiu de 121 (2.1.296) para 117.

Segundo o relato, curl, Node e openssl na mesma máquina aceitam a cadeia, e apontar NODE_EXTRA_CA_CERTS para a raiz não resolveu. Não há confirmação de que voltar para a 2.1.303 resolva esse caso, nem posição oficial da Anthropic sobre a lista de bloqueio. Se a sua falha é só num MCP e a cadeia dele passa por emSign, registre isso na issue com o log do --debug: é esse tipo de dado que separa os dois bugs.

Se a trava de versão vai segurar o seu agente principal por alguns dias, dá para manter um segundo agente de programação no terminal enquanto isso: a Verboo Code roda com tokens ilimitados.

Claude Code "SSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT)": como resolver