Claude Code publicó el 2 de septiembre la versión 2.1.259, un release largo en el que destacan dos incorporaciones que apuntan al mismo sitio: hacer que la herramienta funcione en entornos donde no hay nadie delante de la pantalla. Una es managedMcpServers, que permite a una organización servir servidores MCP a todos sus usuarios de una vez. La otra es --permission-prompts none, un flag para hosts desatendidos que resuelve el problema clásico del headless: el proceso que se queda esperando eternamente una respuesta que nadie va a dar.
Hay además un tercer cambio, mucho menos vistoso, que conviene mirar antes de actualizar, porque modifica el significado de un ajuste que quizá ya tengas puesto.
El administrador pone los servidores MCP y el usuario no los configura
Hasta ahora, repartir un servidor MCP entre un equipo significaba una de dos cosas: meterlo en un .mcp.json dentro del repositorio —lo que lo ata a ese proyecto y exige que cada usuario apruebe el servidor la primera vez— o pedirle a cada persona que lo añadiera a mano con claude mcp add. Ninguna de las dos escala bien cuando lo que quieres es que toda la organización tenga acceso a la misma herramienta interna.
El nuevo ajuste gestionado managedMcpServers resuelve eso: los servidores se declaran una vez en la configuración gestionada y llegan a todos los usuarios. La forma de cada entrada es la misma que la de un .mcp.json, así que no hay que aprender un formato nuevo: tipo de transporte, URL y cabeceras.
Con una restricción que define el diseño entero: solo se admiten servidores HTTP y SSE. Las entradas que nombren un comando local a ejecutar se ignoran. Tiene todo el sentido —desplegar por política una configuración que ejecuta un binario en la máquina de cada empleado es exactamente el tipo de cosa que no debe poder hacerse desde un fichero remoto—, pero implica que un servidor MCP que hoy corres en local vía stdio no se puede distribuir así. Hay que exponerlo por HTTP primero.
Para credenciales, la configuración de MCP admite expansión de variables de entorno con ${VAR} y valores por defecto con ${VAR:-valor}, además de un headersHelper que apunta a un script encargado de devolver las cabeceras de autenticación en JSON. Es lo que hace viable el escenario real: un servidor corporativo común para todos, con un token distinto por usuario.
Denegar automáticamente no es lo mismo que saltarse los permisos
El segundo añadido es el que más gente va a usar. Hasta ahora, ejecutar Claude Code sin supervisión —en un contenedor, en CI, en un cron, en un flujo de n8n— dejaba dos opciones, y ambas malas. La primera: no tocar nada, y asumir que cualquier acción que requiriese aprobación dejaría el proceso colgado esperando a un humano que no existe hasta que algo lo matara por timeout. La segunda: --dangerously-skip-permissions, que hace exactamente lo que su nombre anuncia y aprueba todo.
--permission-prompts none abre una tercera vía, y la diferencia con la segunda es el matiz importante del release: lo que fuera a abrir un diálogo se deniega automáticamente, en lugar de aprobarse. El proceso no se bloquea y tampoco se convierte en un agente sin frenos: simplemente, todo aquello sobre lo que habría que preguntar recibe un no.
Es el opuesto exacto de saltarse los permisos: en vez de aprobar lo dudoso, lo rechaza.
El detalle que lo hace útil de verdad es que el modo de permisos activo sigue decidiendo, auto mode incluido. Es decir: el flag no anula tus reglas, actúa solo sobre lo que quedaría sin resolver. Todo lo que tu configuración permite explícitamente se ejecuta; todo lo que deniega, se deniega; y lo que caería en la zona gris del «pregúntale al usuario» deja de ser un punto muerto y pasa a ser un rechazo limpio, con su mensaje de denegación, que la sesión puede registrar y tú puedes revisar después.
🔧 Cómo leerlo en la práctica
Si tienes un flujo desatendido corriendo con --dangerously-skip-permissions porque era la única forma de que no se quedase parado, este flag es tu sustituto directo. Cambia el enfoque de trabajo: en vez de confiar en que el agente no hará nada raro, defines por adelantado con reglas de permiso qué puede hacer, y el resto se rechaza solo. La primera ejecución te va a fallar en cosas que no habías previsto, y eso es justamente la información que antes no tenías.
El cambio silencioso: tu lista blanca ya no filtra lo mismo
Y ahora la letra pequeña, que es la parte del release con consecuencias inmediatas. allowedMcpServers pasa a gobernar únicamente los servidores que añaden los usuarios. Antes, esa lista blanca actuaba como filtro general; a partir de la 2.1.259, deja fuera de su alcance a los servidores que llegan por configuración gestionada.
La consecuencia está descrita sin rodeos en el changelog: un servidor declarado en managed-mcp.json que tu lista blanca venía filtrando se cargará solo al actualizar. Si alguien de tu organización había usado allowedMcpServers para dejar fuera un servidor gestionado que no le convencía, ese servidor vuelve a estar activo tras la actualización, sin aviso. Para mantenerlo fuera hay que pasarlo a deniedMcpServers.
Merece la pena recordar cómo casan esas dos listas, porque el emparejamiento no es solo por nombre: serverName hace coincidencia exacta y serverUrl admite patrones glob con comodines, lo que permite denegar por dominio entero en lugar de ir servidor a servidor. Es la vía razonable si lo que quieres es una política del tipo «solo servidores de nuestro dominio interno».
Qué le toca revisar a un freelance en esta versión
Si trabajas solo, managedMcpServers no te aplica: es un ajuste gestionado, pensado para administradores con MDM o configuración corporativa. Pero conviene saber que existe por una razón práctica, y es que cambia lo que puedes ofrecer a un cliente con equipo. Montar un servidor MCP que exponga el CRM interno o el catálogo de una tienda y desplegarlo a las quince personas del departamento deja de requerir que cada una toque su configuración: pasa a ser una entrada en la política de la organización. Es un argumento de venta distinto al de «os instalo esto uno a uno».
El flag de permisos sí te toca directamente si automatizas. Cualquier ejecución de Claude Code lanzada desde n8n, desde un cron o desde un contenedor entra en la definición de host desatendido, y hasta ahora la elección entre «se cuelga» y «aprueba todo» era incómoda de justificar delante de un cliente. Tener una tercera opción que deniega por defecto y respeta tus reglas convierte esos flujos en algo defendible: puedes explicar exactamente qué está autorizado a hacer el agente sin apoyarte en la confianza.
La recomendación concreta para hoy: si actualizas y usas MCP con alguna lista de control, comprueba qué servidores están cargados después de la actualización —claude mcp list, o el panel de /mcp— y verifica que la lista es la que esperabas. Es un minuto de trabajo y es exactamente el tipo de cambio de comportamiento que, si no se mira, se descubre semanas más tarde y por el camino equivocado.
