[abhaypadmanabhan]

Moving the mouse in a bot's browser, then clicking, could take seconds to show. Every move, click and key went to Bops Cloud as its own POST (a sign-in check and a database read each), and the next one waited for the answer. Moves at 20 a second queued behind each other, so a click waited behind them.

Now:

• One socket per bot for input (WS /v1/browser/input). Who may use the bot's browser is asked at the upgrade, again every ROLE_MS (the key too), and at once on orgo-web's access notice, as the watch stream is. Each act gets the same checks as a POST, and BROWSER_METHODS still applies at Cloud and at the runner.
• The Mac's server keeps one socket per person, workspace and bot, and answers the window as soon as an act is on its way. An older Bops Cloud (a plain 404 on the upgrade) gets every act by POST, as before. Take, hand back and refused methods still go by POST, so their refusals keep Bops Cloud's words.
• The window sends moves at about 60 a second and replaces a waiting move or scroll with the newest one. Presses, releases and keys are never dropped or reordered. Your own press rings at once where you pressed.

Shared workspaces and several people. Nothing changes about who may drive: each person's socket is checked as them, and one person drives at a time (the owner's take goes over a member's). Two fixes found while measuring several viewers:

• Second window: someone already watching who opened the browser again (a second Mac, or a second window) saw a blank panel until the page changed. Bops Cloud now says joined when a stream opens, and the runner sends the latest frame. Older runners ignore it.
• Revoked key: an owner watching their own bot was never asked about their key again, so a revoked key kept seeing the bot's signed-in pages. The watch stream now asks again at each look, through the same check as the input socket.

Proof (local two-person stack, a proxy adding 35 ms each way, same probe before and after; median / p90)

	main	this change
Click, from rest	205 / 214 ms	121 / 135 ms
Click, right after moving	1784 / 1866 ms	117 / 133 ms
Click, after 6 s idle	283 / 293 ms	134 / 136 ms
Inputs waiting at the click after moving	18	1
Scroll, frames a second (the probe's wheel driver)	13	26 (57 with wheels at 60 a second)
A Member driving in the shared workspace, click after moving	1716 ms	116 ms
The other person watching sees it	1717 ms	120 ms
Three viewers (Member drives, owner's two windows watch), click after moving	n/a (second window blank)	117 ms; each watcher 121 ms

On the real path (installed Bops, bops.orgo.ai, an Orgo computer, screen-recorded), main took 453 ms per click from rest, and about 3 s right after moving. The real path with this change needs Bops Cloud and an app release to measure. Orgo's computer accounts for about 70 ms of that path (21 ms from input to JPEG on the computer itself).

• node scripts/verify browser-input: the input socket against a fake Cloud, Bops Cloud browser tests 16/16, both TypeScript checks, eslint on the touched files.
• node scripts/test-browser-relay.mjs 15/15; node scripts/test-browser-tab-e2e.mjs 17/17 (the owner and a Member, take over, sign-in, hand back, tabs, links).
• Each new test fails without its change: the socket's checks, the key re-checks (socket and stream), the second window's catch-up, and the own-press ring.
• scripts/probe-browser-speed.mjs (--driver sam --watchers 2 for several people) and scripts/verify browser-speed: the measurement, kept so it can be rerun. Timing logs are off unless BOPS_BROWSER_PROBE=1, and never log typed text.

Order of release: any. An app on the old Cloud uses POST, and the old app on the new Cloud does too. The speedup arrives once both are live.

Reviewed with sol-loop: 3 rounds with gpt-6.1-sol. Sol verdict: approved

🤖 Generated with Claude Code

[TigerYWang]

Merged main (no conflicts) and fixed the review findings:

• Who may drive, at each state write (d2735eb). The input socket kept the access it got at the upgrade until the next ROLE_MS look, but per-bot levels and a bot's computer live only in the owner's state, and orgo-web sends no notice for them. A Member set to Read, hidden, or left without Write on a bot now sharing the computer could keep clicking for up to a minute. After a bot moved, acts still went to the old computer's runner. Now every owner-state write (their Mac, an Admin in People, Bops Cloud's own) asks each open input socket and watch stream of that account again, from the blob as written, with no DB read. A refusal ends it with 4403 and the stream says why; a changed computer ends it with 4409. The hook is onStateWritten in live.ts, so state writers don't import browser.ts (that would make an import cycle that hits ROLE_MS before it's defined). The ROLE_MS look stays for keys and orgo-web.
• Fallback to POST expires (fc3ce0c). A plain 404 now puts that Bops Cloud's address on POST for 10 minutes, then the socket is tried again. It no longer lasts for the server's whole life.
• Heartbeat (both commits). The Mac pings its input socket every 5 s and drops one that didn't answer by the next ping, so after a network change acts stop going into a dead socket within about 10 s. Bops Cloud pings every 15 s and drops silent sockets, which it used to keep and look at every minute for good.
• Test race: the key-revoked watch-stream test now waits for its refused event.

Each fix has a test that fails without it. Bops Cloud browser 16/16, core 369/369, edge 191/191; test-browser-view 4/4; relay 15/15; scripts/verify browser-input and browser-speed pass; both tsc runs and eslint are clean. The e2e passed 17/17 once; two other runs here failed only B2.2 (cursor 25.3 and 26.7 px a frame against 25), which is frame timing on this VM and not code touched here.

Not done: F4 (scripts/verify and FEATURES.md add/add with #186), which is left for #186's rebase.