PR #7889: opening cloud workspaces on mobile, final state

iPhone 17 Pro Max sim · dev build against production · 2026-09-26. Videos are rebuilt from timestamped screenshots at about 3 fps, played in real time. The sim's own recorder was stuck.

Videos

Stopped box (vercel sandbox stop, then confirmed running=false), from tap to live session.

The same box while it's running, freshly launched app, from tap to live session.

Stopped box

1.8s: addressing, the only full-screen wait left

6.0s: last tab mounted, desktop's "waking up" copy

20.9s: box is up, host is still replaying agents

Running box

1.4s: addressing (about 0.5s API, the rest is dev-build JS)

What changed from the PR as opened

Area	PR as opened	Now
Addressing	Only ever minted `access({wake:true})`, so the "optimistic" host still waited for the whole wake: 1.7–2.2s on a running box, the full resume and boot on a stopped one.	Like desktop: `access({wake:false})` addresses right away (~0.45s measured on a stopped box) and the wake runs alongside it, handing back the new domain if the box moved.
Request batching	—	The API client uses `httpBatchLink`, so an address and a wake sent in the same tick share one response. The wake now starts once the address has landed.
Race	—	An address that was requested before a wake landed can't overwrite the wake's newer URL.
Waiting UI	A generic "Connecting…" or a blank spinner	Desktop's copy, "This cloud workspace is waking up…", shown while the box is still being woken. When the wake lands the terminals list refetches and the socket redials straight away.
Tab flicker	A failed terminal list dropped the remembered tab, so the view switched between the terminal and a spinner	The tab is kept until a list actually answers without it. A cloud box whose list is failing shows a spinner instead of "No sessions yet".
Cleanup	A one-use re-export of `getWorkspaceActivityTime` through the desktop sort module, a pointer comment in its test, and long comments	Removed. The shared `workspace-activity` helper and the last-active sort are kept as they were.

Still open (not fixed here)

About 5s of "No sessions yet" after a stopped box wakes. After a resume, host-service answers terminal.list before resumeCrashedAgentSessions has put the agents back, and it puts them under new terminal ids. The fix belongs on the server: either the wake waits for the boot-time resume, or the host reports that it's still restoring. A timer on the client would only hide it.
Wake returns 500 for box 4a35f072 ("Auto-login for Neon branches"): sandbox.setEnvironment answered 401, while wake:false works. On the PR as opened, that workspace can't get past "Starting workspace". Now it gets past that screen but stays on the waking spinner. Not investigated beyond that: it looks like a host-secret mismatch on that box.
For a running box, the waking copy can show for about 0.4s while the first socket connects, because the background wake hasn't come back yet.