Repository navigation
Add a bridge-capable Sprites sandbox provider #17635
Description
Activity
this is built and ready to go:
Identify issue type
Identified as Feature
Confidence: HighRationale
This requests new provider support and bridge capability rather than reporting broken existing behavior.
Evidence
- Requests a new first-party
@ai-sdk/sandbox-spritespackage. - Adds Sprites as a bridge-capable cloud sandbox provider with stable WebSocket URL behavior.
- The comment links an implementation PR that is built and ready.
- Requests a new first-party
An update on this one: @kylemclaren's #16270 had drifted from
mainand no longer built there, so #21967 carries it forward. It mergesmain, moves the package to the current sandbox contract, and lets a freshly created Sprite run the bridge harnesses without pre-provisioning. Kyle is kept as author on every one of his commits, and he gave it an LGTM on #16270.I ran it live against real Sprites: the
101upgrade withagent_bridge_tokenarriving unchanged, the same URL after a reconnect and a reattach, and a Claude Code and a Codex turn each.The repo's own workflows haven't run yet because they need a maintainer's approval on a fork PR. Happy to change anything that would make this easier to review.
Background
The provider-agnostic harness abstraction needs additional first-party cloud choices. Sprites provides a native WebSocket-capable proxy through a Sprite’s single
http_port, making it suitable for the standard Claude Code and Codex bridge flow. Sprites is the first-priority provider in the proposed rollout.Feature Request
Add the first-party
@ai-sdk/sandbox-spritespackage using the provider/session shape and lifecycle conventions established by@ai-sdk/sandbox-vercel, while keeping Sprites-specific behavior out of the core harness and adapters.Bind the bridge service through the Sprite’s single proxied
http_port. ImplementgetPortUrlso it returns the corresponding directly dialablewss://<name>-<suffix>.sprites.app/URL and keeps that URL stable across client reconnects and reattachment to the existing sandbox session.A stock
wsclient must connect using the returned URL plus?agent_bridge_token=${encodeURIComponent(token)}. The complete parameter name and encoded value must reach the in-sandbox WebSocket upgrade unchanged. The connection must require no provider-specific client, custom headers, initialization frame, or application-level handshake.Verify that Claude Code and Codex consume the provider identically through their existing
getPortUrlflow, without provider-specific adapter branches.setNetworkPolicyandsetPortsremain optional and must not gate bridge capability. If the complete contract cannot be maintained, the provider must not be advertised or selected as bridge-capable and may only support non-bridge flows.Related Issues
Extracted from #16100