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.
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.