cua-sandbox cloud windows: SDK defaults region to us-east-1; direct API accepts corrected request but Windows VMs stay in provisioning

[ade5791]

Summary

Using cua-sandbox cloud Windows sandboxes from ThinkForce, I found two related problems:

1. The installed cua-sandbox still defaults cloud region to us-east-1, which appears invalid against the current CUA API.
2. When bypassing the SDK and calling the REST API directly with the corrected payload, Windows VM creation is accepted but the VM never reaches
   unning and remains stuck in provisioning.

Environment

• Repo: rycua/cua
• Package: cua-sandbox
• Installed version: �.1.1
• Workspace slug: 76r8vi26
• Plan: Pro

Problem 1 � SDK default region still appears wrong

I inspected the installed source for cua_sandbox.transport.cloud.CloudTransport.init and it still defaults to:

python region: str = "us-east-1"

That causes Sandbox.create(image=Image.windows()) / Sandbox.ephemeral(Image.windows()) to fail with HTTP 400 unless region is explicitly overridden.

Repro

`python
import asyncio
import os
from cua_sandbox import Sandbox, Image, configure

os.environ['CUA_API_KEY'] = 'REDACTED'
configure(api_key=os.environ['CUA_API_KEY'])

async def main():
async with Sandbox.ephemeral(Image.windows()) as sb:
print(sb)

asyncio.run(main())
`

Result

HTTP 400 on POST https://api.cua.ai/v1/vms

Problem 2 � direct REST request is accepted, but Windows VM stays provisioning

When I bypass the SDK and send this request directly:

json { "os": "windows", "region": "north-america", "configuration": "small" }

�the API accepts it and returns a job + VM name.

Example accepted response

• job_id: 2278f216-1477-444c-8077-60f36efdfadb
• vm: s-windows-imbq3yrruv

Observed behavior

The VM remains in provisioning for 180+ seconds and never reaches
unning:

• 10s ? provisioning
• 20s ? provisioning
• 30s ? provisioning
• 40s ? provisioning
• 50s ? provisioning
• 60s ? provisioning
• 70s ? provisioning
• 80s ? provisioning
• 90s ? provisioning
• 100s ? provisioning
• 110s ? provisioning
• 120s ? provisioning
• 130s ? provisioning
• 140s ? provisioning
• 150s ? provisioning
• 160s ? provisioning
• 170s ? provisioning
• 180s ? provisioning

I also observed earlier Windows VMs eventually move to ailed.

Other VMs observed

• s-windows-6x4y1idayy ? provisioning for 8+ minutes, later failed
• s-linux-eljqz7bd5u ? provisioning, later failed

What I already verified

• Auth works: GET /v1/me succeeds
• Workspace is valid
• Credits are available
• Direct REST POST /v1/vms accepts the corrected Windows payload
• Latest package available on PyPI is �.1.1, but the default region still appears to be us-east-1

Questions

1. Is us-east-1 still supposed to be a valid cloud region for cua-sandbox, or should the SDK default be updated to a geographic region like
   orth-america?
2. Is Windows provisioning currently degraded for workspace 76r8vi26 or more broadly?
3. Can you inspect job 2278f216-1477-444c-8077-60f36efdfadb / VM s-windows-imbq3yrruv?
4. If the SDK default is known-bad, should cua-sandbox be patched to stop defaulting to us-east-1?

Additional detail

I wrote a fuller support packet while debugging this in ThinkForce. Happy to provide more logs if useful.