Google search engine
Inicio Editorial Claude Code 2.1.248 estrena modo `–restricted` y mensajería entre sesiones

Claude Code 2.1.248 estrena modo `–restricted` y mensajería entre sesiones

0
42
Claude Code 2.1.248 estrena modo `--restricted`

Claude Code ha publicado la versión 2.1.248, la tercera en tres días después de la 2.1.246 y la 2.1.247, y esta vez el cambio no es cosmético. Llegan dos piezas que alteran cómo se puede usar la herramienta: un modo restringido que le amputa la capacidad de ejecutar nada, y mensajería entre sesiones que permite que dos instancias abiertas en la misma máquina se hablen. Debajo hay además un TTL de caché configurable por agente, diagnósticos para cuando la configuración corporativa no carga y una tanda de correcciones que resuelve varios de los fallos más molestos de las últimas semanas.

Qué desaparece de la caja de herramientas con --restricted

El nuevo modo se activa con la bandera --restricted al arrancar o con la variable de entorno CLAUDE_CODE_RESTRICTED=1. Lo que hace es directo: elimina las herramientas integradas capaces de ejecutar comandos o código, y también WebFetch. No es un modo de permisos más estricto ni una lista de denegación afinada; es la desaparición de esas herramientas del conjunto disponible.

La diferencia con lo que ya existía importa. Hasta ahora, limitar a Claude Code pasaba por reglas de permisos, listas de allow y deny y el modo automático decidiendo qué aprobar. Todo eso son puertas con cerradura: la herramienta sigue ahí y el sistema decide si la abre. Con el modo restringido no hay puerta. Y al quitar WebFetch de la ecuación se cierra también el camino por el que entra la mayoría del contenido no confiable: si el modelo no puede traerse una página, no puede tragarse instrucciones escondidas en ella y actuar sobre ellas.

Las reglas de permisos son puertas con cerradura. El modo restringido quita la puerta.

El escenario obvio es revisar código ajeno. Clonar un repositorio que no controlas y pedirle a un agente que lo lea es una de las operaciones más rutinarias y peor cubiertas que hacemos: el contenido del repo entra en el contexto y el agente tiene shell. Con --restricted, esa sesión puede leer y explicar sin poder ejecutar nada de lo que ha leído. Lo mismo aplica a análisis de logs de cliente, auditorías rápidas de un plugin de WordPress heredado o cualquier tarea de lectura donde el valor está en entender, no en tocar.

💡 Uso práctico: exporta CLAUDE_CODE_RESTRICTED=1 en el perfil del directorio donde clonas repositorios de terceros, o crea un alias del tipo claude-read que arranque siempre con --restricted. Es más fiable que acordarte de pasar la bandera el día que abres un proyecto que no conoces, que es justo el día en el que se te va a olvidar.

Dos sesiones abiertas ya pueden hablarse en la misma máquina

La segunda novedad es SendMessage y ListAgents: comunicación entre sesiones que corren en el mismo equipo, habilitada ahora también en Bedrock, Vertex y Foundry. Una sesión puede enumerar las demás y enviarles mensajes, y la sincronización funciona incluso con la telemetría desactivada, un detalle nada menor para quien trabaja bajo políticas corporativas que la apagan por defecto.

El cambio de modelo mental es el interesante. Hasta ahora, el paralelismo en Claude Code era vertical: tú lanzabas subagentes desde una sesión y ellos te devolvían el resultado. Esto es horizontal: dos sesiones que abriste por separado, cada una con su propio contexto y su propio directorio, ahora se reconocen. La terminal donde estás refactorizando el backend puede avisar a la que tiene el frontend cargado de que acaba de cambiar el contrato de una API, sin que tú hagas de mensajero copiando y pegando entre pestañas.

Para quien orquesta trabajo con varias ventanas abiertas —una por proyecto de cliente, una para el repo de la web, otra para los flujos de automatización— esto elimina el peaje más tonto del día: ser tú el bus de datos entre dos agentes que están a diez centímetros el uno del otro.

Caché por agente y avisos cuando la configuración no carga

La versión añade experimental.cacheTtl en el frontmatter de los agentes, con valores "5m" o "1h". Es decir: el tiempo de vida de la caché de prompt deja de ser global y pasa a decidirse agente por agente. Tiene sentido inmediato en cuanto tienes subagentes de naturalezas distintas: uno que consultas cincuenta veces en una tarde sobre el mismo código se beneficia de la hora completa, mientras que otro que corre puntualmente no necesita mantener nada caliente. Como es un campo experimental, conviene tratarlo como tal y no montar encima una estimación de costes cerrada para un cliente.

En el apartado de configuración, Claude Code ahora avisa al arrancar cuando falla una configuración gestionada por servidor, y tanto /doctor como /status explican qué no ha podido cargarse. Puede sonar menor, pero cubre un fallo especialmente sucio: hasta ahora, si la configuración que impone la organización no llegaba, la sesión arrancaba igual y se comportaba distinto sin decírtelo. Un aviso explícito convierte media hora de desconcierto en una línea de texto al inicio.

Completa el paquete /usage-credits, dirigido a organizaciones Enterprise facturadas a través de AWS Marketplace, que pueden consultar sus créditos desde la propia terminal.

Los fallos corregidos explican el mes de agosto

La lista de correcciones es tan reveladora como las novedades, porque pone nombre a molestias que mucha gente llevaba semanas atribuyendo a su propia máquina:

  • Prompt caching fallando cada hora en sesiones largas. La causa era la redefinición de herramientas tras renovar el token OAuth: al cambiar la definición, la caché dejaba de servir y se pagaba contexto completo otra vez. Si notabas que una sesión de tarde se volvía cara sin motivo, era esto.
  • Sesiones de Claude Desktop que desaparecían a los 30 días. Un problema de retención que se llevaba por delante historiales de proyectos largos.
  • Bloqueos de login cuando otro proceso retenía el candado de renovación de tokens, un clásico de quien tiene varias instancias abiertas a la vez.
  • Correcciones en MCP, en la terminal de Windows y en permisos de repositorio, tres focos habituales de fricción para quien no trabaja sobre macOS.

Conviene leer esta versión junto a las dos anteriores. La 2.1.247 trajo la herramienta SendFeedback, optimización de costes y mejoras en la seguridad de plugins; la 2.1.246 redujo el tamaño de instalación, mejoró el uso de memoria y arregló las sesiones en segundo plano. Tres días, tres releases, y ninguna de las tres es puramente cosmética.

Qué hacer con esto esta semana

Si tienes la versión fijada en un entorno de producción o en un contenedor de CI, la actualización merece la pena solo por el fallo de caché horaria: es dinero que se estaba yendo sin que nadie lo viera en ninguna gráfica. A partir de ahí, dos hábitos nuevos que cuestan poco de adoptar. El primero, reservar el modo restringido para todo lo que sea leer código, logs o documentación de terceros, y dejar la sesión con ejecución completa para lo que de verdad va a modificar tu proyecto. El segundo, dejar de hacer de intermediario entre tus propias terminales: si tienes dos sesiones abiertas sobre partes distintas del mismo trabajo, ahora pueden coordinarse solas.

El movimiento de fondo es coherente con lo que Anthropic viene empujando todo el mes: más autonomía, pero acompañada de más superficie de control. Un agente que puede hablar con otros agentes y que, cuando hace falta, puede quedarse sin manos.

DEJA UNA RESPUESTA

Por favor ingrese su comentario!
Por favor ingrese su nombre aquí