Configurei o Acesso a Arquivos do Claude Desktop Duas Vezes. Era a Mesma Configuração Ambas as Vezes.

O acesso a arquivos no modo de chat do Claude Desktop estava instável por um tempo: às vezes funcionava, às vezes não, sem um padrão óbvio. A solução padrão, a que o próprio Claude te dá em um chat simples, é editar manualmente o claude_desktop_config.json. Eu fiz isso, e antes mesmo de confirmar que funcionava por conta própria, encontrei outra coisa: as mesmas configurações de sistema de arquivos, listadas sob dois rótulos de barra lateral completamente diferentes, sem nada em lugar algum dizendo que eram a mesma página. Eu só percebi porque habilitei uma extensão não relacionada que dá ao Claude controle direto do Mac e a usei para auditar as configurações corretamente.

Neste artigo

• A pergunta que eu realmente precisava responder
• A solução que não te leva longe
• Uma página, dois rótulos de barra lateral
• O que a auditoria encontrou
• GitHub: o bug que decidiu a arquitetura
• Parece certo não é o mesmo que funciona
• Então, você realmente sabe?
• O que vem a seguir

A pergunta que eu realmente precisava responder

Eu administro uma wiki de operações pessoais, principalmente lida e escrita pelo Claude, em dois Macs. O acesso a arquivos no modo de chat simples do Claude Desktop nunca pareceu totalmente confiável. Funcionava bem em uma sessão e falhava na seguinte, sem nenhuma alteração de configuração que eu estivesse ciente entre elas. A resposta fácil é "basta usar o modo Cowork" e isso é um bom conselho, mas é uma solução alternativa, não um diagnóstico. Eu queria saber o que estava realmente configurado antes de decidir que o acesso mais leve no modo de chat não valia a pena consertar.

A solução que não te leva longe

Peça ao Claude em um chat simples como configurar isso, e ele te direciona para claude_desktop_config.json: o clássico bloco JSON mcpServers, editado manualmente, uma entrada por servidor. Essa é a resposta na maioria dos guias.

Eu escrevi uma entrada de sistema de arquivos escopo e reiniciei. O que eu não fiz, e deveria ter feito, foi verificar se essa entrada estava realmente controlando o acesso, em vez de algo já em execução por baixo dela. Eu nunca isolei um teste limpo de "entrada JSON sozinha, nada mais presente". Ao verificar o que estava realmente concedendo acesso, encontrei uma segunda tela de configurações já ativa e já configurada, sem ideia de há quanto tempo estava em execução ou como se relacionava com o que eu acabara de escrever.

Uma página, dois rótulos de barra lateral

Encontrar uma tela de configurações que eu não sabia que existia foi motivo suficiente para parar de adivinhar. Eu fiz o Claude usar uma extensão separada, habilitada anteriormente para automação não relacionada e dando controle direto do AppleScript e shell do Mac, para ler todos os arquivos de configuração envolvidos em vez de confiar no que qualquer tela única afirmava.

O que isso revelou não eram três sistemas independentes lutando entre si. Era mais especificamente irritante do que isso: a mesma tela de configurações de sistema de arquivos, acessível de dois lugares totalmente diferentes na barra lateral, estilizada de forma idêntica, sem nenhuma referência cruzada dizendo que são a mesma página. Navegue via Aplicativo Desktop → Extensões → Sistema de Arquivos e você chega a uma página. Navegue via Personalizar → Conectores → Sistema de Arquivos e você chega à exata mesma página: mesmo botão, mesmas duas diretórios permitidos, mesma lista de permissões de ferramentas, pixel por pixel. Duas portas, uma sala, e nada em nenhuma das portas menciona a outra.

Por baixo disso está uma segunda coisa genuinamente separada: o bloco mcpServers do claude_desktop_config.json, que é a maneira antiga de fazer isso e ainda é correta para qualquer coisa que a Anthropic não tenha incorporado na tela unificada (um servidor de terceiros como o GitHub, por exemplo).

Então, a verdadeira configuração não são três superfícies de configurações. É um método JSON legado e um sistema GUI atual que a própria navegação da Anthropic aparentemente não consegue decidir se deve chamar de "Extensões" ou "Conectores", arquivando a tela idêntica sob ambos os rótulos em meio à renomeação, sem nada explicando a sobreposição. Se você usou o Claude Desktop ao longo de meses de mudanças incrementais na interface, essa é exatamente a configuração para acreditar que você configurou duas coisas diferentes quando configurou uma coisa duas vezes, através de menus com aparência diferente, em dois momentos diferentes.

O que a auditoria encontrou

O acesso ao sistema de arquivos já estava sendo controlado pela tela GUI antes mesmo de eu escrever a entrada JSON, configurada em algum ponto anterior que não tenho uma memória clara, para uma lista maior de pastas do que as duas que eu realmente queria. Pastas antigas de projetos antigos, adicionadas uma a uma ao longo de meses e nunca revisadas como um todo. Nada dramático no conteúdo. Apenas mais do que o pretendido, sem memória de ter escolhido tudo isso deliberadamente.

A parte que realmente importava: a entrada JSON que eu acabara de escrever estava agora ativa no mcpServers ao mesmo tempo que a própria configuração da tela GUI, e eu não tinha ideia se a entrada JSON estava fazendo algo, fazendo algo parcial ou totalmente inerte. Eu não queria descobrir por tentativa e erro o que duas instâncias separadas de servidores MCP de sistema de arquivos reivindicando a mesma função realmente produzem. Melhor palpite: ferramentas duplicadas no seletor, talvez seleção ambígua de ferramentas se ambas registrarem algo como read_file. Isso é um palpite, não um modo de falha confirmado. Então eu removi a incerteza em vez de resolvê-la: reverti a entrada JSON de volta para um mcpServers: {} vazio e deixei a tela GUI ser a única coisa ativa.

O verdadeiro risco aqui não é que o método JSON esteja morto, o que não posso afirmar ter provado de nenhuma maneira. É que se a visão rotulada como Extensões e a visão rotulada como Conectores da mesma funcionalidade algum dia mostrarem listas de pastas diferentes, não apenas duas portas para uma sala, mas duas portas que realmente se separaram, nada na interface do usuário te diz qual delas é real, ou que elas divergiram de alguma forma. Isso vale a pena verificar lado a lado em vez de assumir que estão sincronizadas.

GitHub: o bug que decidiu a arquitetura

Separadamente, eu queria acesso de push ao GitHub. A Anthropic tem um conector de Integração GitHub nativo: Configurações → Conectores, clique, autorize, pronto. O caminho óbvio.

Exceto que, desde o final de julho de 2026, há um bug aberto e não resolvido onde as permissões OAuth desse conector concedem acesso de leitura normalmente, mas toda operação de escrita falha com 403 Resource not accessible by integration, incluindo git push. Confirmado, relatado, ainda aberto quando verifiquei. Ative essa opção sem checar e você obtém um conector que parece conectado e falha silenciosamente na única coisa que você precisava.

A solução alternativa: o próprio servidor MCP oficial do GitHub, executado localmente via Docker, autenticado com um token de acesso pessoal de granularidade fina em vez do aplicativo GitHub da Anthropic.

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"