Sesgo declarado, como siempre: enseño Claude Code a equipos de ingeniería, así que tiendo a contar bien lo que pasa en Anthropic. Precisamente por eso esta pieza va de hechos verificables y de qué te toca revisar, no de vender que la herramienta ahora es "más segura" sin matices.
La novedad de esta semana no es una feature vistosa: son dos controles de gobernanza que solo nota quien administra Claude Code para un equipo. Pero si ese eres tú, los dos cierran agujeros que probablemente tenías abiertos sin saberlo.
Los hechos
El 23 de junio, la versión 2.1.187 de Claude Code introdujo dos cambios en permisos y seguridad. Los dos vienen redactados como capacidades nuevas, no como bugfixes.
1. sandbox.credentials: el sandbox deja de leer tus secretos. El
changelog lo dice literal: se añade el ajuste sandbox.credentials para
bloquear que los comandos en sandbox lean ficheros de credenciales y
variables de entorno con secretos. Hasta ahora, un comando que Claude Code
ejecutaba dentro del sandbox corría con tu entorno: si tenías un
AWS_SECRET_ACCESS_KEY, un token de npm o un .env a mano, ese comando podía
leerlos. Con el ajuste activado, esa superficie se cierra: el código que corre
en sandbox no ve los secretos del entorno.
2. Las restricciones de modelo de tu organización ya se cumplen en todas
partes. El mismo release añade las restricciones de modelo configuradas por
la organización al selector de modelo, al flag --model, al comando /model
y a la variable de entorno ANTHROPIC_MODEL, con un mensaje explícito —
"restricted by your organization's settings"— cuando alguien elige un modelo
restringido.
Este segundo punto es más sutil de lo que parece, así que conviene precisarlo.
La capacidad de restringir qué modelos puede usar tu gente ya existía: la
mencionamos al hablar del ajuste gestionado enforceAvailableModels en la guía
de adopción de Fable 5. Lo que cambia
ahora es dónde se aplica. Restringir el selector no sirve de mucho si
cualquiera puede saltárselo arrancando con --model claude-fable-5 o exportando
ANTHROPIC_MODEL. La 2.1.187 lleva la restricción también a esas vías. Si tu
política dependía solo de lo que se ve en el menú, hasta esta versión tenías una
puerta lateral abierta.
Qué te afecta, según quién seas
Si administras Claude Code para un equipo. Aquí está casi todo el trabajo, y es trabajo bueno: dos controles que antes no podías garantizar.
- Si tienes una política de modelos permitidos (por coste, por compliance o
porque no quieres que nadie ponga por defecto un modelo al doble de precio),
revisa que sigue en pie tras actualizar y da por cerrado el flanco de
--modelyANTHROPIC_MODEL. Lo que antes era "confiamos en que nadie lo cambie a mano" ahora es una restricción que se cumple sola. - Decide si activas
sandbox.credentials. Para equipos que corren Claude Code con credenciales reales en el entorno —y casi todos lo hacen— es el ajuste por defecto que probablemente querías. El mecanismo es el mismosettings.jsonde siempre; lo trabajamos en el curso de permisos, settings y seguridad, que ya incluye una lección dedicada a sandboxing.
Si corres Claude Code de forma desatendida o con secretos en el entorno.
Piensa en CI, en claude -p headless, en agentes que ejecutan comandos sin una
persona delante. Ahí es donde sandbox.credentials más rinde: un comando que se
tuerce —tuyo o sugerido por el agente— deja de poder exfiltrar un token solo por
estar en el mismo proceso. No es magia ni sustituye a tu gestión de secretos,
pero recorta una vía concreta de fuga. Si montas pipelines de Claude Code en CI,
encaja con lo que vemos en
CI, GitHub Actions y code review.
Si usas Claude Code de forma interactiva y no administras nada. Cero deberes.
Si tu organización no restringe modelos, no notarás nada en el selector. Y
sandbox.credentials es un ajuste que alguien tiene que activar: si nadie lo
toca, tu flujo sigue igual que ayer. El único cambio visible posible es que, si
tu empresa sí restringe modelos, ahora verás el mensaje de "restringido por la
configuración de tu organización" también al usar --model o /model, donde
antes quizá te dejaba pasar.
Si no haces nada. No se rompe nada. Ninguno de los dos cambios altera el
comportamiento por defecto sin que alguien lo configure: las restricciones de
modelo solo aplican si tu organización las tiene puestas, y sandbox.credentials
es opt-in. Actualizar no te cambia el día a día por sí solo.
Qué llevarte
sandbox.credentialsbloquea que los comandos en sandbox lean ficheros de credenciales y variables de entorno con secretos. Es opt-in y vive en tusettings.json. Si corres Claude Code con secretos en el entorno, es el ajuste que probablemente querías por defecto.- Las restricciones de modelo de la organización ahora se aplican en el
selector, en
--model, en/modely enANTHROPIC_MODEL, con un mensaje claro al elegir un modelo bloqueado. Si tu política dependía solo del menú, esto cierra la puerta lateral. - Nada cambia solo: los dos son controles que tú activas. Para quien no administra ni tiene política de modelos, actualizar no cambia el flujo.
Preguntas rápidas
¿sandbox.credentials me protege de fugas de secretos en general?
No lo trates como una bala de plata. Cierra una vía concreta —que el código en
sandbox lea credenciales del entorno— pero no sustituye a una buena gestión de
secretos ni a tus reglas de permisos. Es una capa más, no la única.
¿Tengo que reescribir mi política de modelos? No. Si ya usabas un ajuste gestionado para restringir modelos, la 2.1.187 solo amplía dónde se cumple. Tu única tarea es confirmar tras actualizar que la restricción sigue como esperas y que ya no se puede saltar por flag o variable de entorno.
¿Esto aplica a la API o solo a Claude Code? Estos dos cambios son de Claude Code (el CLI), según su changelog. No tocan el contrato de la API de Messages.
¿Y si gestionas Claude Code para un equipo? Decidir qué modelos permites, con qué presupuesto y bajo qué política de sandbox y permisos es exactamente el tipo de criterio que trabajamos en la formación en directo para equipos — sobre vuestro repo, vuestros secretos reales y vuestra configuración.