A person holding the wheel stops the Bot's clicks, not its shell

[beardthelion]

agent-computer refuses a Bot's page actions while a person holds the wheel, and lets its shell and its workspace writes through. assertBotMayAct (agent-computer/src/control.ts:234) is called from the navigate handler (agent-computer/src/index.ts:699) and from the acting handler shared by /click, /type, /key and /scroll (:896). grep finds no third call site. /exec (:802) and /files/write (:828) never ask.

The server cannot cover for it. server/src/computer/gateway.ts proxies /control/* but never consults control before forwarding an action, and the state lives in the computer process by design (control.ts:9-11, "a takeover that the browser does not know about is not a takeover"). Those two call sites are the whole of the enforcement.

Driving a real agent-computer with a person holding the wheel, on d293f23:

holder: {"holder":"human", ...}

/click        -> 409 {"error":"A person has control of the computer right now...","humanHasControl":true}
/type         -> 409  (same)
/key          -> 409  (same)
/scroll       -> 409  (same)
/navigate     -> 409  (same)
/exec         -> 200 {"exitCode":0,"stdout":"BOT_RAN_THIS_WHILE_HUMAN_DROVE\nubuntu\n"}
/files/write  -> 200 {"path":"pwned.txt","bytes":48}

The write is on the volume afterwards, and the command ran as the container user.

This is the property the project states in two places. control.ts:5-7: "While a person holds control every acting call from the Bot is refused, because two drivers on one page is how a Bot clicks Confirm on a form a human was still filling in." README.md:146: "While a person is driving, Bot actions are refused rather than queued." The README also presents the shell as one of those actions: "A shell, not just a browser: a Bot can run a command in its workspace, install what it needs, and process a file it saved."

A person takes the wheel at a login wall, or because they no longer trust what the Bot is doing. Right now the Bot can keep running commands and rewriting the workspace underneath them while they are mid-sign-in, and the surface shows a takeover in force.

It reads as an omission rather than a decision. /exec arrived in c647fa4 ("Run OpenBot as one container, and give a Bot a shell", #62), after the wheel already existed; that commit touches no control code and adds no guard. Nothing in the repo states an exemption, and no test asserts the current behaviour either way. The comment above /exec addresses policy ("the gateway already asked the deployment's policy and wrote the audit row before this was called"), which is a different gate: policy decides whether a Bot may ever run a command, the wheel decides whether it may act right now.

One reading defends it. control.ts explains the rule as "two drivers on one page", and /exec does not touch the page. That does not cover /files/write, which mutates the same workspace volume the person is told belongs to the Bot, and it is nowhere written down.

Reading looks genuinely different. /files/read and /files/list are not acting, and a Bot that has just been stopped still has to be able to say what it was doing, so I would leave those open.

Happy to send a PR.