Cloudflare pone fecha al cambio en Sandbox SDK: migra de HTTP/WebSocket a RPC antes del 9 de julio
Cloudflare deprecó el 9 de junio de 2026 los transports HTTP y WebSocket del Sandbox SDK. Para agentes que ejecutan código en Workers, la fecha importante es el 9 de julio: después de ese día las nuevas versiones ya no los incluirán.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Cloudflare publicó el 9 de junio de 2026 una de esas notas que muchos equipos ignoran hasta que rompe un deploy: el Sandbox SDK depreca los transports HTTP y WebSocket, y las versiones publicadas después del 9 de julio de 2026 ya no los incluirán. La ruta recomendada pasa a ser RPC transport.
Esto importa porque los sandboxes se están volviendo pieza central de agentes que ejecutan código, levantan previews, manipulan archivos o corren validaciones dentro de Workers. Si tu agente depende de Sandbox SDK y no revisas el transport, puedes tener un fallo de runtime justo cuando actualices dependencias.
Qué cambia exactamente
La guía de migración dice que HTTP y WebSocket dejarán de existir en nuevas versiones después del 9 de julio. Para migrar, Cloudflare recomienda configurar SANDBOX_TRANSPORT con valor rpc en el Worker o pasar transport: "rpc" al llamar getSandbox().
El documento de transport modes explica el mapa actual:
- HTTP transport: cada operación del SDK hace una solicitud separada al contenedor;
- WebSocket transport: ya está deprecated;
- RPC transport: multiplexa operaciones sobre una conexión persistente con un protocolo mejorado.
La señal de producto es clara: Cloudflare quiere estabilizar el canal entre Durable Object, Worker y contenedor para workflows agentic más largos.
Por qué esto no es solo mantenimiento
En un agente de coding o análisis, el sandbox no es un detalle. Es donde el modelo ejecuta comandos, instala paquetes, lee archivos y produce evidencia. Si la comunicación con el contenedor es lenta, frágil o difícil de recuperar, el agente parece "tonto" aunque el modelo esté bien.
La migración a RPC debería revisarse con tres pruebas:
- una sesión larga con varios comandos y archivos;
- un caso con logs o streaming de salida;
- una interrupción controlada para ver cómo se recupera el flujo.
El riesgo real: actualizar sin mirar
El peor escenario no es tener que cambiar una variable. Es que el SDK suba en CI, preview o producción y el agente pierda acceso al sandbox por una configuración vieja. Por eso conviene tratar esta nota como deuda con fecha.
Checklist rápido:
- busca
SANDBOX_TRANSPORT,transportygetSandbox()en tu repo; - fija versión del SDK mientras pruebas la migración;
- activa RPC en staging;
- corre una tarea real de agente, no solo un
hello world; - documenta el rollback antes de actualizar después del 9 de julio.
La demanda se infiere por señales actuales: changelog oficial, guía de migración, uso creciente de sandboxes para agentes y queries como Cloudflare Sandbox SDK RPC transport, SANDBOX_TRANSPORT rpc, Sandbox SDK WebSocket deprecated y agent sandbox Workers. No hay tooling SEO conectado, así que no invento volumen.
Si todavía estás decidiendo cuándo un agente necesita sandbox, empieza por la arquitectura mínima de un agente en producción. La lectura breve: si el sandbox es la computadora del agente, el transport es parte de la confiabilidad del producto.