O Repo Não Deveria Ter Voto na Própria Confiança

Em 24 de abril de 2026, a Anthropic publicou o GHSA-q5hj-mxqh-vv77, um bypass do diálogo de confiança do Claude Code com CVSS 7.7. Trinta e sete dias antes, em 18 de março, o mesmo projeto publicou o GHSA-mmgp-wc2j-qcv7 com a mesma pontuação CVSS. Dois bypasses do diálogo de confiança no mesmo agent runtime na mesma janela de seis semanas não são coincidência.¹²

A forma compartilhada é a lição. No bug de março, o .claude/settings.json controlado pelo projeto era lido antes da verificação de confiança do workspace, e um modo de permissão bypassPermissions nesse arquivo satisfazia trivialmente o gate.² No bug de abril, um repositório malicioso envia um arquivo commondir forjado dentro de .git/, o avaliador de confiança segue o ponteiro para um diretório no qual o usuário já confia, e o workspace herda essa confiança sem nunca exibir o diálogo.¹

Duas linhas de texto dentro de um repo que ninguém ainda abriu poderiam votar um workspace como confiável. As superfícies de nível de projeto que o repo entrega (hooks, configurações de servidor MCP, skills, subagentes) podem então ser resolvidas contra esse voto, seja com avidez no início da sessão ou de forma preguiçosa quando invocadas. As defesas a jusante em qualquer agent runtime ficam atrás de uma decisão que o runtime toma antes de elas existirem.

TL;DR

• Dois CVEs de bypass do diálogo de confiança do Claude Code em 37 dias mostram o que quebra quando bytes controlados pelo repo influenciam a confiança do workspace.
• A correção imediata do lado do usuário é atualizar para uma versão posterior à 2.1.84, restringir os caminhos confiáveis em ~/.claude.json e evitar a confiança ampla em caminhos pais como ~/Projects.
• A correção estrutural é um invariante de ordem de carregamento: não interprete nenhum byte do workspace até que o caminho do workspace seja explicitamente confiável.

O Que os Dois Avisos Realmente Corrigiram

Ler os patches em conjunto com a documentação torna a falha de ordem de carregamento visível. As versões corrigidas reordenam quais bytes o avaliador de confiança tem permissão para consultar.

O aviso de março descreve o Claude Code resolvendo configurações de projeto antes de resolver a confiança do workspace. A correção na 2.1.53 inverte essa ordem, de modo que a verificação de confiança não lê mais o .claude/settings.json de dentro do workspace antes de o usuário ter decidido.² O aviso de abril descreve o avaliador de confiança seguindo o arquivo commondir no diretório .git/ de um repositório enquanto resolve o próprio caminho do workspace. A correção na 2.1.84 impede que o avaliador honre o conteúdo de commondir controlado pelo repositório durante a avaliação de confiança.¹ Ambos os patches restauram o mesmo invariante: a decisão de confiança não deve consultar bytes que vivem dentro do workspace candidato.

As classificações de CVE apontam para o mesmo diagnóstico. O bug de março é registrado como CWE-807, Reliance on Untrusted Inputs in a Security Decision.³ O bug de abril é registrado como CWE-20 mais CWE-77, Improper Input Validation e Improper Neutralization of Special Elements, porque a resolução de commondir tratou bytes controlados pelo repositório como autoritativos.¹ CWEs diferentes, mesma suposição quebrada: um portão de segurança que lê do artefato que está protegendo.

A Superfície Pré-Confiança É Mais Ampla do Que a Referência de Configurações Sugere

O Claude Code documenta um conjunto de superfícies de início de sessão controladas pelo projeto que devem permanecer atrás do gate de confiança. Os dois CVEs nesta classe provam que o invariante quebra quando qualquer uma delas entra na própria decisão de confiança. As superfícies se dividem em dois escopos que a análise de confiança precisa manter separados: bytes que vêm com um repositório clonado e bytes que um usuário adiciona localmente a um workspace sem fazer commit.⁴⁵⁶⁷

Superfícies committed no repo (vêm com git clone). Esta é a superfície de cadeia de suprimentos. Qualquer coisa neste grupo é o que um atacante controla quando cria um repositório malicioso.

Superfícies locais ao workspace (não committed por padrão). Estas não chegam ao workspace pela cadeia de suprimentos; aparecem quando um usuário local as cria. Ainda vivem dentro do caminho do workspace, então o gate de confiança ainda deve tratá-las como não confiáveis até que o caminho seja aprovado.

Os hooks vivem dentro de .claude/settings.json em vez de em um arquivo separado; o aviso de abril descreve o atacante populando essa chave diretamente.¹⁶ O bug de abril também revelou uma superfície que não faz parte da referência de configuração do Claude Code: um arquivo interno do git chamado commondir, que resolve uma worktree de volta para seu repositório pai.⁸ Um repositório malicioso que entrega um layout commondir forjado herda a confiança do caminho-alvo quando o Claude Code segue o ponteiro durante a avaliação de confiança. A superfície interna do git quebrou a contagem de superfícies de configuração do projeto, e essa é a verdadeira lição. A taxonomia não está fechada. A superfície de ataque é definida por quais bytes são lidos antes do diálogo disparar, e qualquer coisa que possa influenciar a resolução de caminho ou a configuração está em jogo.

O padrão é o mesmo que MCP Servers Are the New Attack Surface nomeou em outra altitude.⁹ Os servidores MCP explodiram a superfície de provedores de ferramentas antes que o ecossistema alcançasse as implicações. O bypass do diálogo de confiança é a mesma forma uma camada abaixo. Cada recurso de conveniência que permite a um repositório pré-configurar o agente adiciona uma linha à taxonomia acima. Cada linha é candidata ao próximo CVE da classe.

A Parte de Trás do Armário: Um Invariante de Ordem de Carregamento, Não um Diálogo Mais Esperto

Paul Jobs ensinou Steve que a parte de baixo de um armário merece o mesmo cuidado que o acabamento.¹⁰ A metáfora do armário não é decorativa aqui. Ela é a espinha da correção.

Um diálogo de confiança é a parte de trás do armário. Os usuários não veem a ordem de carregamento. Veem um diálogo, clicam em Confiar e presumem que cada byte dentro do workspace está inerte até esse clique. A implementação tem que merecer essa presunção. Quando não merece, a presunção é a superfície de ataque.

A ordem de carregamento é o invariante que decide se a presunção é merecida. O modelo mínimo implícito pelos dois avisos e pela documentação pública de configurações do Claude Code é aproximadamente:²¹⁶

1. Ler as configurações do usuário em ~/.claude/settings.json.
2. Ler as configurações do usuário em ~/.claude/settings.local.json.
3. Avaliar se o caminho do workspace atual é confiável.
4. Se não for, exibir o diálogo. Se o usuário clicar em Confiar, persistir o caminho.
5. Ler o .claude/settings.json com escopo de projeto dentro do repo.
6. Ler o .claude/settings.local.json com escopo de projeto.
7. Resolver hooks, servidores MCP, skills e subagentes a partir das configurações mescladas.
8. Executar os hooks SessionStart.

Os avisos não documentam cada passo exatamente, e o posicionamento de skills, subagentes e MCP em relação à mesclagem de configurações é detalhe de implementação que o usuário não vê. O que os avisos estabelecem é a fronteira no passo 3. Qualquer coisa resolvida antes do passo 3 está na zona de entrada confiável. Qualquer coisa resolvida no passo 3 ou depois não deve consultar bytes do workspace. O bug de março trocou os passos 3 e 5: as configurações do projeto eram resolvidas primeiro, e o modo de permissão que essas configurações estabeleciam (bypassPermissions) satisfazia trivialmente a verificação de confiança no passo 3.² O bug de abril moveu o ataque para dentro do próprio passo 3: a resolução do caminho do workspace consultava um arquivo commondir controlado pelo repositório, e uma forjadura fazia a verificação de confiança resolver contra o caminho confiável escolhido pelo atacante.¹ De qualquer forma, quando o passo 7 ou o passo 8 chega, o workspace já está confiável, e cada superfície de nível de projeto carrega contra esse voto.

A regra que a parte de trás do armário exige é uma frase: não interprete nenhum byte dentro do workspace até que o usuário tenha confiado explicitamente no caminho do workspace. Não o .claude/settings.json. Não o commondir. Não o CLAUDE.md. Não uma lista de nomes de arquivos. Não um arquivo de hook. Não uma configuração de servidor MCP. Se vive dentro do workspace, o código que decide a confiança não olha para isso.

O Visual Studio Code lançou essa correção em maio de 2021 como Workspace Trust (release 1.57). A classe principal de confiança em pastas não produziu um bypass publicado desde que o recurso foi lançado, embora questões adjacentes em torno de domínios confiáveis e comportamento de extensões continuem a aparecer.¹¹¹² A versão 2.1.53, a correção referenciada pelo aviso de março, trouxe a versão do Claude Code desse invariante ao reordenar os passos 3 e 5.² A versão 2.1.84, a correção referenciada pelo aviso de abril, trouxe o invariante ao se recusar a seguir arquivos commondir controlados pelo repositório durante a avaliação de confiança.¹ Ambos são patches que restauram o invariante em vez de inventar uma nova defesa.

The Steve Test puxa o próximo fio: Blake assinaria seu nome nisso?¹³ A resposta para o Claude Code nesta janela de seis semanas é não, porque o vendor já assinou, lançou e corrigiu duas vezes bypasses dessa classe. Essa é a barra do vendor a corrigir. Minimum Worthy Product é o padrão a que a assinatura se refere.¹⁴ Mínimo é uma restrição de escopo, não um desconto de qualidade. Um diálogo de confiança minimamente viável é um diálogo que bloqueia o caso barato. Um diálogo de confiança minimamente digno é o primeiro passo de uma ordem de carregamento que se recusa a interpretar qualquer byte do repositório antes de o usuário ter decidido. O produto que você entrega é o conjunto de bytes que você se recusa a interpretar até receber permissão.

Três Correções Que o Invariante Exige

A regra é o invariante. Três padrões decorrem diretamente dela.

Gates de mão única. O código que constrói confiança lê apenas o caminho, o clique do usuário e o estado de confiança persistido fora do workspace em ~/.claude.json.¹⁵ Nada mais. Qualquer refatoração em que um arquivo do workspace contribua para a decisão de confiança é uma regressão.

Sem confiança transitiva via resolução de caminho. O invariante preferido é que worktrees, submódulos, arquivos incluídos e alvos de symlink recebam cada um seu próprio prompt. O Workspace Trust do Visual Studio Code, por outro lado, permite que a confiança em pastas pais se aplique às subpastas, e essa escolha é o que a confiança ampla em caminhos pais como ~/Projects explora quando a resolução de caminho é forjada. A regra mais estrita paga alguns diálogos a mais e remove toda a superfície de confiança transitiva; a regra mais frouxa mantém o atrito baixo e aceita que bugs de resolução de caminho se tornem bugs de resolução de confiança.¹¹

Fixtures adversariais no teste de regressão de ordem de leitura de confiança. Um repo adversarial deliberadamente forjado que faz commit de arquivos canário no workspace. O teste afirma que nenhum caminho de código lê esses canários antes que o diálogo seja confirmado. Se uma mudança futura no runtime ler qualquer arquivo canário durante a avaliação de confiança, a build falha. CWE-501, Trust Boundary Violation, é a família mais ampla que vale a pena rastrear na taxonomia de testes ao lado das classificações mais específicas CWE-807 e CWE-20/CWE-77 que os avisos publicados já usam.¹⁶

Nenhum dos três é caro. O primeiro é a ausência de código. O segundo custa atrito visível ao usuário. O terceiro é uma passada de engenharia mais disciplina depois disso. O comprometimento do bootstrap de confiança é uma categoria onde a postura usual de defesa em profundidade não se aplica, porque toda camada a jusante da confiança roda contra a decisão de confiança que o workspace acabou de ajudar a tomar. Defesa fora da confiança é impossível de construir na camada de scaffolding porque o scaffolding é exatamente o que o workspace pode ler quando a confiança é resolvida.

O vendor tem que entregar o invariante. Os CVEs de bypass do diálogo de confiança são como observadores medem se o vendor está atingindo a barra. Dois em seis semanas não é ruído. É um sinal de que o invariante não foi codificado na suíte de testes como uma asserção que a build aplica. Até que esteja, o próximo CVE da classe é uma questão de encontrar a décima entrada.

O repo não deveria ter voto na própria confiança. Confiança é a única decisão em que o artefato sendo avaliado não deve ajudar a tomar. Cada outra camada da defesa do agente (hooks, skills, validators, detectors, guards) vive a jusante desse único voto. Quando o voto está fraudado, o trabalho a jusante é mobília. O acabamento do armário não salva a parte de trás.

FAQ

O que é o bypass do diálogo de confiança do Claude Code?

Um bypass do diálogo de confiança do Claude Code acontece quando um workspace não confiável é tratado como confiável antes que o usuário o aprove explicitamente. No CVE de março de 2026, configurações controladas pelo repo influenciaram o modo de permissão antes de a confiança ser avaliada. No CVE de abril de 2026, um layout forjado de git worktree/commondir fez com que a confiança fosse resolvida através de um caminho já confiável.

Como devo restringir os caminhos confiáveis em ~/.claude.json?

Abra ~/.claude.json e inspecione o map projects. Procure por entradas em que hasTrustDialogAccepted seja true em diretórios que não contêm mais código ativo, em caminhos pais amplos como ~/Projects e em qualquer caminho que se sobreponha a layouts adjacentes a worktrees. A confiança por repositório adiciona diálogos, mas evita que um caminho pai aceito cubra silenciosamente todos os filhos.

Por que a confiança em caminho pai é perigosa para o Claude Code?

A confiança em caminho pai é perigosa porque um diretório aceito pode cobrir muitos workspaces filhos. Se a resolução de caminho for forjada, ou se uma worktree maliciosa apontar de volta para esse pai, o repo filho pode herdar uma confiança que nunca lhe foi concedida. A confiança por repo adiciona atrito, mas evita confiança transitiva entre repos não relacionados.

Qual invariante evita bypasses do diálogo de confiança?

O invariante é: não interprete nenhum byte dentro do workspace até que o usuário confie explicitamente no caminho do workspace. O código de confiança pode ler o caminho, o clique do usuário e o estado de confiança persistido fora do repo. Não deve ler .claude/settings.json, CLAUDE.md, .mcp.json, hooks, skills, commondir ou qualquer arquivo controlado pelo repo antes do diálogo.

Referências