Cloud sandbox: VM reaches running and noVNC works, but computer-server control API (*-api.cua.sh /cmd, /ws) returns persistent HTTP 502; cua-sandbox stuck in _wait_for_server_ready

Summary

On freshly created cloud Linux sandboxes ("source": "incus"), the VM reaches status: running and the noVNC web desktop works, but the computer-server control API endpoint returns HTTP 502 Bad Gateway on every request. As a result the official cua-sandbox Python SDK can never connect; it loops in _wait_for_server_ready for 6+ minutes and times out.

It looks like the public gateway/proxy for *-api.cua.sh is up (it answers, with 502), but the computer-server upstream inside the incus VM is not listening / not routed. The noVNC path (*-vnc.cua.sh) on the same VM works fine, so this seems isolated to the control-API route, not the VM itself.

Environment

• cua-sandbox Python SDK v0.1.16
• Cloud sandbox, OS: linux, "source": "incus"
• Created via POST https://api.cua.ai/v1/vms (also reproduces through the SDK)

Steps to reproduce

1. Create a cloud Linux VM:

   POST https://api.cua.ai/v1/vms
   Authorization: Bearer <CUA_API_KEY>
   {"os": "linux", "region": "us-east-1", "configuration": "small"}
   

   succeeds; VM transitions to status: running ("source": "incus").
2. Open the noVNC desktop: https://<name>-vnc.cua.sh/vnc.html returns HTTP 200, desktop renders. OK
3. Hit the computer-server control API on the same VM:

   GET/POST https://<name>-api.cua.sh/cmd      -> HTTP 502 Bad Gateway
   WS       wss://<name>-api.cua.sh/ws          -> fails (502 / cannot upgrade)
   

   Returns 502 on every request, on every fresh VM, sustained over several minutes (not a boot delay).
4. The SDK resolves the endpoint to https://<name>-api.cua.sh/cmd and loops in _wait_for_server_ready, receiving 404/502, never becoming ready (times out after 6+ min).

Expected

The computer-server control API (/cmd, /ws) on <name>-api.cua.sh should become reachable once the VM is running, so the SDK's _wait_for_server_ready succeeds and screenshot/click/type work, matching what the noVNC endpoint already does.

Actual

<name>-vnc.cua.sh returns 200 (works), but <name>-api.cua.sh/cmd + /ws return persistent 502 Bad Gateway; the SDK never connects.

Questions

1. Is the computer-server expected to be auto-started and routed on cloud incus Linux VMs, or does it require a manual start / specific image / plan / region?
2. Is the 502 on *-api.cua.sh (while *-vnc.cua.sh is healthy) a known gateway/routing issue on the cloud incus image?
3. If there is a flag, region, or plan tier required for the control API to be exposed, could that be documented? I did not find it in the cloud docs.

Happy to provide the exact VM name, job_id, and timestamps privately if useful. Thanks!

Start by reproducing the cloud Linux VM flow from POST /v1/vms, then inspect the endpoint used by the SDK's _wait_for_server_ready. Compare the working *-vnc.cua.sh route with the failing *-api.cua.sh /cmd and /ws routes. Done means the control API is reachable after the VM reports running and the SDK completes readiness checks.