TabRunner

Check that the browser agent is reachable before driving it. Reports whether the TabRunner extension is connected to this bridge, which extension it is, whether it has a provider ready to think with, and what to do when any of that is missing. Call this first, and again after any connection error.

Takes no parameters.

Give TabRunner a task to do in the user's real Chrome, with their existing logins and sessions to navigate, read pages, click, type, fill forms and extract data. Describe the goal in plain language, as you would to a person; TabRunner plans and executes the steps itself. Returns immediately: follow the task with get_status. By default the task works in its own background tab (reusing this chat's tab while it lives, or opening url / the start page) and leaves the user's current page alone; pass background: false only when the task is explicitly about what the user is looking at.

Where the current task stands: the plan and the steps taken; when it ends, the answer, the question it stopped on or the error. By default this WAITS for the next change instead of returning immediately, so following a ten-minute task costs one call per real event. Keep calling it until state is done, error, or question.

Reply to the question a task stopped on (state: question) and let it continue. TabRunner stops to ask before consequential actions (paying, sending on the user's behalf, deleting or submitting), so relay the question to the user and send THEIR decision, never your own.

Send a note into a task that is already running, such as a correction, an extra constraint or a change of approach. It lands between tool calls, so the task absorbs it without restarting. Use this instead of stop+run when the goal is still the same.

Stop this client's current task, or pass runId to cancel one of its queued tasks. It cannot stop another client's task. Stopping leaves the browser as it is. Nothing is undone.

A picture of the tab this client's task or direct-control session is driving. Start one with run or browser_start first. It never captures another client's tab or the user's current page as a fallback.

Takes no parameters.

Forget the current chat and start clean. TabRunner keeps a separate chat for each connected client. Each task continues the previous ones, so it remembers the pages it visited and what it found. Reset only when the new task has nothing to do with the old one.

Takes no parameters.

Summarize this chat's history so far, so every task replays a summary instead of the whole transcript. The raw messages stay in the user's panel; only what the model re-reads changes, and nothing is deleted. Reach for it when a long chat's tasks get slow or one dies on a context-length error. Cannot run while a task is in flight.

Takes no parameters.

Open a direct-control session and get the first page snapshot. Use this instead of run when you want to drive step by step rather than hand TabRunner the whole task. run is still the better choice for anything long or open-ended, because TabRunner's own model plans it. Like run, it works in a background tab of its own (reusing the tab the previous session drove while it lives, or opening url / the start page) and leaves the page the user is reading alone; pass url to open a specific page. Pass background: false only when the task is about the page the user is on. State the goal: it names the chat the user will see in TabRunner's history, and every action you take is recorded under it. IMPORTANT: driving directly bypasses TabRunner's own model and its rule of stopping to ask before consequential actions, so paying, sending on the user's behalf, deleting, or submitting is yours to put to the user first.

The current page as an accessibility tree with a ref on every interactive element. This is how you see, and where every ref you click comes from. Refs belong to the snapshot that produced them: after anything changes the page, re-read before acting.

Takes no parameters.

The requests the driven tab has made since the session attached, with method, URL, status and failures. Tells 'the server answered with an error' apart from 'the page never sent it'. Response bodies are not captured; re-fetch a GET with browser_evaluate when the payload matters.

The driven tab's console messages and uncaught exceptions since the session attached. When a page misbehaves for no visible reason, the JavaScript error usually names the broken piece.

Navigate the driven tab and return the new page's snapshot.

Click by ref with a real trusted event, not a synthetic dispatch a site can ignore. Returns the resulting page. Take the ref from the most recent snapshot.

Type into whatever is focused. Click the field first. Real keystrokes, so a site's own handlers fire. Returns the resulting page.

Set the value of a field by ref. Supports text inputs, textareas, selects (by option label or value) and contenteditable. The value is set the way the page's own code notices, so it lands where typed keystrokes don't (pages that swallow key events, focus that won't stick). Pass an empty string to clear a field. Returns the resulting page.

Run JavaScript in the driven tab's page context and get the result back. Promises are awaited; return only JSON-serializable values, not DOM nodes. For what the other tools cannot do: reading an attribute the tree omits, piercing shadow DOM, calling the page's own functions, fetching an endpoint the page itself uses. Results are bounded and credential-shaped values are stripped. A direct session has no plan gate. The code runs exactly as written, so the consequential-action rule (paying, sending on the user's behalf, deleting, submitting, by fetch or any other means) is yours to put to the user first. Returns the resulting page.

A single key press: "Enter" to submit, "Escape" to dismiss, "Tab" to move on. Returns the resulting page.

Scroll the driven tab and return what is now in view. Content below the fold is not in a snapshot until you scroll to it.

Open tabs with their id, title and URL. These are all the tabs the user has open, so pass query to get only the ones you need. Find the one you need, then switch.

Point every later action at another tab. The tab does not need to be on screen: actions work on background tabs too. It comes to the front only while the user is watching the tab you leave; otherwise the work goes on without moving their screen.

Close this client's direct-control session and remove its on-page badge. Call it when you're done. Other clients and the panel keep their own tasks. A session left open expires after a few idle minutes.

Takes no parameters.