Respond to browser task
task_respondPerform one action from the current observation in the user's browser (click, type, select, press a key, navigate, scroll and similar), resolve an uncertain effect, mark the task done, or report it blocked. Actions can change or submit data on websites; risky ones pause for the user's approval in Chrome, and an action whose effect is uncertain is never repeated automatically. BrowserPair dismisses page confirmation dialogs (outcome.dialogs); to answer one OK, repeat that action with acceptDialog: true and the user approves it in Chrome. Downloads need the download capability and the user's approval of each one: a blocked download is listed in outcome.downloads; repeat that action with allowDownload: true to ask the user. BrowserPair never returns file contents. To put a file into a page's file field (an element of kind file, or the button that opens the chooser), use kind upload with file; it needs the file_upload capability and the user's approval. When the task has several tabs, the observation lists them in task_tabs; use kind switch_tab with tabId to go back to one, or kind close_tab with tabId to close one this task opened (opened_by_task) that is not current. The observation's open_tabs lists tabs the user already has open on the task's sites (other_open_tabs counts the rest without naming them); use kind adopt_tab with one of those tabIds to work in it instead of opening a new tab. An adopted tab stays the user's: ending the task never closes it. For responsive QA, kind set_viewport with width/height needs viewport_control and changes only the task-owned tab viewport; BrowserPair resets it when control ends. To have the user do one step on the page (sign in, a CAPTCHA or code, a payment step) and then continue yourself, use kind user_step with a reason. For sign_in or verification you may name a structured method such as passkey, QR code, security key or device approval; BrowserPair asks the user in Chrome, never handles that secret/device factor itself, and returns a fresh observation when they press Continue. When the user should continue themselves (for example to review, sign in or pay), end with kind handoff and a summary: the current tab stays open in front of them and BrowserPair stops acting. Never invent refs that are not in task_state.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| task_id | Yes | ||
| interaction_generation | Yes |