What's Allowed

whats-allowed-mcp

Você escreveu uma regra de negação. Será que ela fez alguma coisa? Um servidor MCP que lê todos os arquivos de configuração que alimentam as permissões do seu agente, mostra qual deles vence e lista as regras que seu cliente aceita e depois ignora.

Por quê

As regras de permissão para um agente de codificação não estão em um único arquivo. Elas estão em até cinco ao mesmo tempo: uma política gerenciada em toda a máquina, o arquivo do projeto que sua equipe faz commit, um arquivo local ignorado pelo git, seu arquivo de usuário e o que uma sessão escreveu. Elas são mescladas e depois avaliadas como negar → perguntar → permitir, onde a primeira correspondência vence e a especificidade não desempata.

Essa mesclagem já é difícil o suficiente. A parte que realmente incomoda é que vários formatos de regra são aceitos e depois silenciosamente não fazem nada:

• Write(docs/**) — as permissões de arquivo são verificadas apenas contra regras Edit(path) e Read(path). Uma regra de caminho Write, NotebookEdit, MultiEdit ou Glob é aceita e nunca consultada.
• Bash(command:rm *) — uma regra não pode corresponder ao campo de conteúdo principal de uma ferramenta com a forma param:value. Ela é ignorada, porque um comando composto a contornaria.
• "mcp__*" em allow — um glob de permissão sem ancoragem é ignorado e não aprova nada automaticamente.
• Read(/.env) nas configurações de usuário — uma única barra inicial ancora na origem das configurações, então essa regra protege ~/.claude/.env, não o .env em cada um dos seus projetos.
• Bash(git push origin main) em allow sob um Bash(git push *) em deny — uma regra de negação não pode carregar exceções de lista de permissões, então a regra de permissão é inalcançável.

O Claude Code avisa sobre algumas dessas coisas na inicialização, em um histórico de rolagem que você já perdeu quando se importa. Nada as coleta, nada informa o próprio agente e nada mostra a você o panorama mesclado em todos os cinco arquivos ao mesmo tempo. Isto faz.

Como é

Dado um projeto .claude/settings.json:

{
  "permissions": {
    "deny": ["Bash(git push *)", "Write(.env*)"],
    "allow": [
      "Bash(npm run test:*)",
      "Bash(git push origin main)",
      "Bash(npx *)",
      "Bash(ls*)"
    ]
  }
}

…e um usuário ~/.claude/settings.json com "deny": ["Read(/.env)"] e "defaultMode": "acceptEdits", whats_allowed retorna (caminhos encurtados aqui):

# Permissions in force

| | |
|---|---|
| Settings files contributing | 2 of 5 possible |
| Permission rules | 3 deny, 0 ask, 4 allow |
| Blanket allow rules (whole tool) | 0 |
| Hook commands wired to agent events | 0 |
| Extra directories granted | 0 |
| Rules that do not do what they look like | 5, of which 1 is ignored outright |

## Default mode

`defaultMode` = **`acceptEdits`**, set in User (`~/.claude/settings.json`).

> Automatically accepts file edits and common filesystem commands (`mkdir`,
> `touch`, `mv`, `cp`) for paths in the working directory or additionalDirectories.

## First things to look at

- **Path rule on Write** — `Write(.env*)` in Project settings
- **Allow rule on a command runner (`npx`)** — `Bash(npx *)` in Project settings
- **Trailing wildcard with no word boundary** — `Bash(ls*)` in Project settings

Sete regras. Cinco delas fazem algo diferente do que aparentam — e aquela em que todos apostariam, Write(.env*), nunca é consultada.

Ferramentas

Instalação

Claude Desktop (um clique, sem terminal): baixe o whats-allowed-mcp-<version>.dxt mais recente de Releases e abra-o com o Claude Desktop (duplo clique, ou Configurações → Extensões → Instalar Extensão…). O servidor e suas dependências vêm dentro do pacote — sem npm, sem instalação do Node.

Registre com o Claude Code (disponível em todas as sessões):

claude mcp add --scope user whats-allowed -- npx -y whats-allowed-mcp

Ou em qualquer configuração de cliente MCP:

{
  "mcpServers": {
    "whats-allowed": {
      "command": "npx",
      "args": ["-y", "whats-allowed-mcp"]
    }
  }
}

git clone https://github.com/stcmain/whats-allowed-mcp
cd whats-allowed-mcp && npm install && npm run build
# then point your client at node /path/to/whats-allowed-mcp/dist/index.js

Publicado como whats-allowed-mcp no npm e como io.github.stcmain/whats-allowed-mcp no MCP Registry.

Sem configuração. Sem variáveis de ambiente. Respeita CLAUDE_CONFIG_DIR quando você moveu sua configuração de usuário.

O que verifica e o que se recusa a adivinhar

Cada descoberta corresponde a um comportamento que a Anthropic documenta, e cada uma tem link para o parágrafo de onde vem. Não há pontuação de risco, nem classificação de gravidade, nem heurística de "regra suspeita" — essas coisas produzem bobagens confiantes em configurações comuns.

Relatado:

• Regras de caminho em Write / NotebookEdit / MultiEdit / Glob, que as verificações de permissão de arquivo nunca consultam
• Regras Tool(param:value) direcionadas ao campo de conteúdo principal de uma ferramenta, que são ignoradas por completo
• Globs de nome de ferramenta sem ancoragem em allow, que não aprovam nada automaticamente
• :* usado em qualquer lugar além do final de um padrão de shell, onde os dois pontos são literais
• Regras /path nas configurações de usuário, que ancoram no diretório de configuração em vez do seu projeto
• * final sem limite de palavra — Bash(ls*) também corresponde a lsof
• Regras de permissão em comandos que executam outros comandos (npx, docker exec, bash -c, xargs, devbox run…), que aprovam o que vier depois deles
• Regras Bash que tentam restringir uma URL, que os próprios documentos chamam de frágeis
• Regras de permissão que uma regra de negação ou pergunta alcança primeiro
• Regras declaradas em mais de um arquivo

Deliberadamente não relatado:

• Se suas regras expressam o que você quer. Isso é um julgamento sobre intenção e este servidor não tem um.
• Sombreamento que precisa de um solucionador de curingas. Uma regra de permissão só é chamada de inalcançável quando a regra bloqueadora é um padrão de prefixo que comprovadamente a cobre. Qualquer coisa mais sutil é deixada de lado em vez de adivinhada, então isto sub-relata de propósito.
• Um veredito para um comando hipotético. Veja abaixo.

Limitações honestas

• Não simula a decisão do seu cliente. Não existe ferramenta "seria git push permitido", e isso é uma escolha de design: o conjunto de comandos somente leitura integrado do Claude Code, a remoção de wrappers (timeout, nice, xargs…), a divisão de comandos compostos, o estado do sandbox e os resultados do hook PreToolUse participam da resposta real. Um veredito estático seria confiantemente errado com frequência suficiente para valer menos do que nenhuma resposta. Use /permissions no seu cliente para a visão ao vivo; use isto para entender por que ele diz o que diz.
• Flags de linha de comando são invisíveis. --allowedTools, --disallowedTools, --permission-mode e --settings ficam entre a política gerenciada e as configurações locais, e não estão no disco.
• Regras de sessão adicionadas via /permissions caem em arquivos que este servidor lê, mas regras adicionadas para uma única sessão não.
• Relata; não corrige. Nada é editado, e nenhuma descoberta é jamais uma recomendação para excluir uma regra. Onde os documentos dão uma forma corrigida, ela é citada; onde não dão, a descoberta para na observação.
• ~/.claude/settings.local.json é relatado, mas não classificado. Ele existe e o Claude Code escreve nele; a tabela de precedência publicada lista quatro escopos e não o inclui. Este servidor se recusa a inventar sua posição.
• O esquema do Claude Code é o modelo. Outros clientes com seus próprios sistemas de permissão não são analisados.
• Nunca lê o histórico do git e não diz quem adicionou uma regra ou quando. git log -p .claude/settings.json faz isso melhor.

Notas de design / modelo de ameaça

• Sem processos filhos. Sem shell. Sem rede. Sem gravações. As únicas APIs Node usadas são leituras node:fs, node:path e node:os. Não há importação child_process em lugar nenhum do código-fonte, então nada em um arquivo de configurações pode ser executado ao lê-lo — incluindo os comandos de hook e scripts apiKeyHelper sobre os quais ele relata.
• Valores env nunca são lidos — apenas nomes. Arquivos de configurações são um dos lugares mais comuns para uma chave de API em texto puro, e uma ferramenta que colasse uma em uma janela de contexto seria pior do que o problema que resolve. O mesmo se aplica a apiKeyHelper: a presença é relatada, o script não é lido nem executado.
• Strings originadas de configurações são cercadas e rotuladas. O texto das regras e os comandos de hook precisam ser mostrados para serem úteis. Eles são emitidos dentro de spans de código inline com crases neutralizadas, pipes escapados e quebras de linha achatadas, para que uma string maliciosa não possa sair do span ou de uma tabela markdown, e cada bloco carrega uma nota permanente de que o texto citado são dados de um arquivo, não instruções.
• dir é o único caminho controlado pelo modelo, e é limitado por construção: resolvido, com caminho real e obrigado a ser um diretório existente. A partir daí, apenas nomes de arquivo fixos são lidos — .claude/settings.json, .claude/settings.local.json, o arquivo de configuração do usuário, o caminho da política gerenciada da plataforma. Sem globbing, sem travessia, sem leituras arbitrárias de arquivos.
• Trabalho limitado: teto de 2 MB por arquivo, uma varredura limitada ao procurar a raiz do projeto, e arquivos que falham ao analisar são relatados como não analisados em vez de parcialmente adivinhados.
• Descobertas são conservadoras por construção. Cada verificação está ancorada ao comportamento documentado; qualquer coisa que exigisse um julgamento sobre intenção não é relatada. Para uma ferramenta que as pessoas usam para decidir se uma proteção é real, sub-relatar é o modo de falha correto.

Quem faz isto

Construído por Shift The Culture — operamos uma empresa de uma pessoa com agentes de IA e enviamos as ferramentas que precisávamos nós mesmos. Este servidor é gratuito e licenciado sob MIT, sem amarras.

Tem três irmãos, todos também gratuitos e MIT:

• whats-running-mcp — o que está realmente rodando na máquina agora, em vez do que uma transcrição antiga afirma.
• whats-loaded-mcp — o que está consumindo sua janela de contexto antes de você digitar: descrições de habilidades, arquivos de memória e suas importações.
• whats-inherited-mcp — o que um checkout que você não escreveu diz ao seu agente para fazer: arquivos de instrução, hooks e os servidores MCP que ele declara.

O restante dessas ferramentas é pago:

• Agent Fleet Ops Kit ($29) — os outros modos de falha de rodar três ou quatro agentes em uma máquina: duas sessões editando o mesmo checkout, um servidor de desenvolvimento que ninguém possui (então o agente testa um aplicativo diferente do que edita) e servidores MCP vazados de sessões travadas que seguram portas e RAM por semanas. Prefere PayPal? Mesmo kit no Payhip.
• Agent Reliability Kit ($29) — um hook Stop e dois CLIs que bloqueiam um turno quando um agente afirma "concluído" contra um repositório, URL ou build que nunca foi realmente verificado. Prefere PayPal? Mesmo kit no Payhip.

O servidor acima permanece gratuito e MIT de qualquer forma — não tem upsell, nem telemetria e nenhuma dependência dos kits pagos.

Patrocinadores

Este servidor é MIT e permanece MIT. Não há edição pro, nem telemetria, e nada é retido da versão gratuita. O patrocínio é como a manutenção é paga sem que nada disso mude.

Ainda sem patrocinadores — a primeira vaga está aberta. Patrocinadores empresariais ganham seu nome ou logotipo nesta seção, nos três servidores irmãos e na página de patrocinadores. Níveis, exatamente o que é o posicionamento e o que ele explicitamente não compra: https://shifttheculture.media/sponsor

Indivíduos: https://paypal.me/ShiftTheCultureLLC — qualquer valor, sem vantagens, sem nível.

Licença

MIT © Zachary Pampu