What's Allowed

Muestra lo que tu agente de codificación puede hacer sin preguntarte: cada archivo de configuración que contribuye con reglas de permisos, cuál gana, qué se ejecuta sin supervisión y las reglas que el cliente acepta y luego ignora.

GitHubPrueba este MCPPatrocinado

Documentación

whats-allowed-mcp

Escribiste una regla de denegación. ¿Hizo algo? Un servidor MCP que lee cada archivo de configuración que alimenta los permisos de tu agente, muestra cuál gana y enumera las reglas que tu cliente acepta y luego ignora.

Por qué

Las reglas de permisos para un agente de codificación no están en un solo archivo. Están en hasta cinco a la vez: una política administrada a nivel de máquina, el archivo de proyecto que tu equipo confirma, un archivo local ignorado por git, tu archivo de usuario y lo que haya escrito una sesión. Se fusionan y luego se evalúan denegar → preguntar → permitir, donde la primera coincidencia gana y la especificidad no rompe el empate.

Esa fusión ya es bastante difícil. La parte que realmente muerde es que varias formas de reglas se aceptan y luego silenciosamente no hacen nada:

Write(docs/**) — los permisos de archivo se verifican solo contra las reglas Edit(path) y Read(path). Una regla de ruta Write, NotebookEdit, MultiEdit o Glob se acepta y nunca se consulta.
Bash(command:rm *) — una regla no puede coincidir con el campo de contenido principal de una herramienta con la forma param:value. Se ignora, porque un comando compuesto la eludiría.
"mcp__*" en allow — un glob de permitir sin anclar se omite y no auto-aprueba nada.
Read(/.env) en la configuración de usuario — una sola barra inicial ancla en el origen de la configuración, por lo que esa regla protege ~/.claude/.env, no el .env en cada uno de tus proyectos.
Bash(git push origin main) en allow bajo un Bash(git push *) en deny — una regla de denegación no puede llevar excepciones de lista de permitidos, por lo que la regla de permitir es inalcanzable.

Claude Code advierte sobre algunas de estas al inicio, en un scrollback que ya has perdido para cuando te importa. Nada las recopila, nada le dice al agente mismo, y nada te muestra la imagen fusionada de los cinco archivos a la vez. Esto lo hace.

Cómo se ve

Dado un proyecto .claude/settings.json:

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

…y un usuario ~/.claude/settings.json con "deny": ["Read(/.env)"] y "defaultMode": "acceptEdits", whats_allowed devuelve (rutas acortadas aquí):

# 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

Siete reglas. Cinco de ellas hacen algo distinto de lo que parecen — y la que todos habrían apostado, Write(.env*), nunca se consulta en absoluto.

Herramientas

Herramienta	Qué responde
`whats_allowed`	El titular: qué archivos contribuyen, cuántas reglas de denegar/preguntar/permitir, el `defaultMode` ganador, permisos generales, hooks y cuántas reglas se comportan mal. Empieza aquí
`permission_sources`	Qué archivo decide, en orden de precedencia — existencia, estado de análisis, conteos de reglas y a qué ancla un `/` inicial en cada uno
`rule_findings`	Cada regla cuyo comportamiento documentado difiere de su intención aparente, con la razón y la alternativa documentada
`unattended_surface`	Lo que procede sin que nadie mire: modo predeterminado, permisos generales, directorios extra, guardas de modo y comandos de hook

Instalación

Claude Desktop (un clic, sin terminal): descarga el último whats-allowed-mcp-<version>.dxt desde Releases y ábrelo con Claude Desktop (doble clic, o Configuración → Extensiones → Instalar Extensión…). El servidor y sus dependencias vienen dentro del paquete — sin npm, sin instalación de Node.

Regístrate con Claude Code (disponible en cada sesión):

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

O en cualquier configuración de cliente MCP:

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

Desde el código fuente

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 en npm y como io.github.stcmain/whats-allowed-mcp en el Registro MCP.

Sin configuración. Sin variables de entorno. Respeta CLAUDE_CONFIG_DIR cuando has movido tu configuración de usuario.

Qué comprueba y qué se niega a adivinar

Cada hallazgo corresponde a un comportamiento que Anthropic documenta, y cada uno enlaza al párrafo del que proviene. No hay puntuación de riesgo, ni clasificación de gravedad, ni heurística de "regla sospechosa" — esas producen tonterías seguras en configuraciones ordinarias.

Reportado:

Reglas de ruta en Write / NotebookEdit / MultiEdit / Glob, que las comprobaciones de permisos de archivo nunca consultan
Reglas Tool(param:value) dirigidas al campo de contenido principal de una herramienta, que se ignoran por completo
Globs de nombre de herramienta sin anclar en allow, que no auto-aprueban nada
:* usado en cualquier lugar excepto al final de un patrón de shell, donde los dos puntos son literales
Reglas /path en la configuración de usuario, que anclan en el directorio de configuración en lugar de en tu proyecto
* final sin límite de palabra — Bash(ls*) también coincide con lsof
Reglas de permitir en comandos que ejecutan otros comandos (npx, docker exec, bash -c, xargs, devbox run…), que aprueban lo que les sigue
Reglas de Bash que intentan restringir una URL, que los propios documentos llaman frágiles
Reglas de permitir a las que una regla de denegar o preguntar llega primero
Reglas declaradas en más de un archivo

Deliberadamente no reportado:

Si tus reglas expresan lo que quieres. Eso es un juicio sobre la intención y este servidor no tiene uno.
Sombreado que necesita un solucionador de comodines. Una regla de permitir solo se llama inalcanzable cuando la regla bloqueante es un patrón de prefijo que la cubre de manera demostrable. Cualquier cosa más sutil se deja sola en lugar de adivinarse, por lo que esto sub-reporta a propósito.
Un veredicto para un comando hipotético. Ver abajo.

Limitaciones honestas

No simula la decisión de tu cliente. No existe una herramienta de "¿se permitiría git push?", y eso es una elección de diseño: el conjunto de comandos de solo lectura integrado de Claude Code, el despojo de envoltorios (timeout, nice, xargs…), la división de comandos compuestos, el estado del sandbox y los resultados del hook PreToolUse participan todos en la respuesta real. Un veredicto estático sería erróneamente seguro con la frecuencia suficiente como para valer menos que ninguna respuesta. Usa /permissions en tu cliente para la vista en vivo; usa esto para entender por qué dice lo que dice.
Las banderas de línea de comandos son invisibles. --allowedTools, --disallowedTools, --permission-mode y --settings se sitúan entre la política administrada y la configuración local, y no están en el disco.
Las reglas de sesión añadidas a través de /permissions aterrizan en archivos que este servidor lee, pero las reglas añadidas solo para una sesión no.
Reporta; no arregla. Nada se edita, y ningún hallazgo es jamás una recomendación para eliminar una regla. Donde los documentos dan una forma corregida, se cita; donde no, el hallazgo se detiene en la observación.
~/.claude/settings.local.json se reporta pero no se clasifica. Existe y Claude Code escribe en él; la tabla de precedencia publicada enumera cuatro ámbitos y no lo incluye. Este servidor se niega a inventar su posición.
El esquema de Claude Code es el modelo. Otros clientes con sus propios sistemas de permisos no se analizan.
Nunca lee el historial de git, y no te dice quién añadió una regla ni cuándo. git log -p .claude/settings.json hace eso mejor.

Notas de diseño / modelo de amenazas

Sin procesos hijos. Sin shell. Sin red. Sin escrituras. Las únicas APIs de Node utilizadas son lecturas node:fs, node:path y node:os. No hay importación de child_process en ningún lugar del código fuente, por lo que nada en un archivo de configuración puede ejecutarse al leerlo — incluidos los comandos de hook y los scripts apiKeyHelper que reporta.
Los valores de env nunca se leen — solo los nombres. Los archivos de configuración son uno de los lugares más comunes para una clave API en texto plano, y una herramienta que pegara una en una ventana de contexto sería peor que el problema que resuelve. Lo mismo aplica a apiKeyHelper: se reporta la presencia, el script no se lee ni se ejecuta.
Las cadenas escritas en la configuración están delimitadas y etiquetadas. El texto de las reglas y los comandos de hook deben mostrarse para ser útiles. Se emiten dentro de tramos de código en línea con backticks neutralizados, tuberías escapadas y nuevas líneas aplanadas, para que una cadena manipulada no pueda salir del tramo ni de una tabla de markdown, y cada bloque lleva una nota permanente de que el texto citado son datos de un archivo, no instrucciones.
dir es la única ruta controlada por el modelo, y está acotada por construcción: resuelta, con ruta real y requerida como directorio existente. Desde allí solo se leen nombres de archivo fijos — .claude/settings.json, .claude/settings.local.json, el archivo de configuración del usuario, la ruta de política administrada de la plataforma. Sin globbing, sin recorrido, sin lecturas de archivos arbitrarios.
Trabajo acotado: un límite de 2 MB por archivo, un recorrido limitado al buscar la raíz del proyecto, y los archivos que no se pueden analizar se reportan como no analizados en lugar de adivinarse parcialmente.
Los hallazgos son conservadores por construcción. Cada comprobación está anclada al comportamiento documentado; cualquier cosa que requiera un juicio sobre la intención no se reporta en absoluto. Para una herramienta que la gente usa para decidir si una barandilla es real, sub-reportar es el modo de fallo correcto.

Quién hace esto

Construido por Shift The Culture — dirigimos una empresa unipersonal con agentes de IA y publicamos las herramientas que nosotros mismos necesitábamos. Este servidor es gratuito y con licencia MIT, sin condiciones.

Tiene tres hermanos, todos también gratuitos y MIT:

whats-running-mcp — lo que realmente se está ejecutando en la máquina ahora mismo, en lugar de lo que afirma una transcripción antigua.
whats-loaded-mcp — lo que está consumiendo tu ventana de contexto antes de que escribas: descripciones de habilidades, archivos de memoria y sus importaciones.
whats-inherited-mcp — lo que un checkout que no escribiste le dice a tu agente que haga: archivos de instrucciones, hooks y los servidores MCP que declara.

El resto de esas herramientas son de pago:

Agent Fleet Ops Kit ($29) — los otros modos de fallo de ejecutar tres o cuatro agentes en una máquina: dos sesiones editando el mismo checkout, un servidor de desarrollo que nadie posee (así que el agente prueba una aplicación distinta de la que edita), y servidores MCP filtrados de sesiones bloqueadas que mantienen puertos y RAM durante semanas. ¿Prefieres PayPal? Mismo kit en Payhip.
Agent Reliability Kit ($29) — un hook de Stop y dos CLIs que bloquean un turno cuando un agente afirma "hecho" contra un repo, URL o build que nunca se comprobó realmente. ¿Prefieres PayPal? Mismo kit en Payhip.

El servidor anterior sigue siendo gratuito y MIT de cualquier manera — no tiene venta adicional, ni telemetría, ni dependencia de los kits de pago.

Patrocinadores

Este servidor es MIT y sigue siendo MIT. No hay edición pro, ni telemetría, ni nada retenido de la versión gratuita. El patrocinio es cómo se paga el mantenimiento sin que nada de eso cambie.

Aún no hay patrocinadores — el primer espacio está abierto. Los patrocinadores de empresa obtienen su nombre o logotipo en esta sección, en los tres servidores hermanos y en la página de patrocinadores. Niveles, exactamente qué es la colocación y qué no compra explícitamente: https://shifttheculture.media/sponsor

Individuos: https://paypal.me/ShiftTheCultureLLC — cualquier cantidad, sin ventajas, sin nivel.