Computer Use

Computer Use

How to work in web pages through Emperor's built-in browser. The browser_* tools drive an Agent tab that the user can watch, pause, take over or close in the workspace Browser pane.

Before you start

• Is the GUI needed? Prefer an API, a CLI, web_fetch or a file tool when one can do the job. Use the browser only for the part that must happen in a page.
• Are the tools there? If no browser_* tools are in your tool list, computer use is switched off. Tell the user they can turn it on in 设置 › 电脑操作; do not try to drive a browser another way.
• What can the driver do right now? Call ui_get_capabilities once when unsure. It lists the available drivers, their actions and current limitations. Cross-origin iframe observation and clicking work; typing into one is disabled.

The loop: observe → act → verify

1. browser_open the page (one tab per task is usually enough).
2. browser_observe to get a semantic snapshot. Elements carry refs such as r3.12.
3. Act on refs from the latest observation: browser_fill, browser_click, browser_select, browser_press, browser_scroll.
4. Observe again and check the result the user asked for (the confirmation text, the new URL, the filled value) — not just that an action was sent.
5. Use browser_wait for things that load later (text appears, URL changes, an element becomes enabled) instead of observing in a tight loop.

Rules that keep this reliable:

• Refs are valid only for the observation that produced them. After a navigation or a new observation, use the new refs; a STALE_ELEMENT error means observe again, STALE_TARGET means the tab or page you meant is gone.
• Several actions may run on one snapshot (fill, fill, click), as long as the page did not navigate in between.
• A click on something covered by an overlay is refused before anything is sent ("covered by another element"): close the overlay (cookie banner, dialog) first.
• Long pages are cut to a budget. Narrow browser_observe with role or nameContains, use diff: true to see only what changed, and pass the returned cursor to read the rest — rather than scrolling blindly.
• browser_screenshot is for the user or for a vision-capable model; the semantic snapshot is the primary source of truth.

Desktop apps (macOS)

• desktop_list_windows, then desktop_bind one window, then desktop_observe it; act on refs from the latest observation as in a browser. A lost target means its window closed or its app quit: list windows and bind again.
• If the app you need is not running, start it without taking the front (open -g -a "<App name>"), then list its windows.
• Protected apps never appear in desktop_list_apps or desktop_list_windows, even while running: System Settings, Keychain Access, Passwords, system authorization prompts, Emperor itself, and apps on the user's protected list. When the app you need is one of them, tell the user it is protected and cannot be controlled (its absence from the list does not mean it is closed), and stop. Never try to reach it another way, and never quit, kill, relaunch or script the user's apps through the shell (kill, pkill, killall, osascript, repeated open).
• Work in the background; the user keeps using their computer. Clicks on elements with a press action, desktop_fill and menu commands (desktop_menu, then desktop_menu_select) never bring the app forward. Native apps also take desktop_type and desktop_press in the background. Chrome, Edge and Electron apps (VS Code, Slack, …) ignore keys while in the background: run their commands from the menu (for example View › Command Palette...), set text with desktop_fill, and pick results by clicking them.
• Prefer background routes; a step that needs the front gets it automatically. In the default continuous-allow mode, actions that need the front (keys or menus in Chrome, Edge or Electron apps such as VS Code, coordinate clicks, drags) bring the window forward themselves without asking, and the front goes back to the user's app when the task ends. In per-item mode, call desktop_activate before the first such step: the user is asked once per task, and after that those actions bring the window forward themselves. Run foreground steps back to back: transient UI such as VS Code's command palette closes as soon as the app loses the front. If the user declines, stop and say what is left for them. Never use AXRaise to bring a window forward.
• Verify with desktop_observe: it reads the window in the background, even on another desktop (Space). Read text with desktop_observe and includeText: true, never by scrolling; never bring a window forward just to read it or take a screenshot. desktop_scroll by page, with the ref of a native app's document or list, runs in the background.
• A minimized window stays bound; desktop_activate restores it.
• Pass the text field's ref to desktop_type. Never read or change input method settings (no Control+Space, no input menu, no defaults).
• To add text at the end of a native document or field, use desktop_fill with append: true and only the new text (start it with a line break for a new line). It works in the background, does not depend on where the insertion point is, and keeps the document's formatting. Replace a field's whole content with desktop_fill without append only when that is the task: in a formatted document it drops the formatting. Use desktop_type for a terminal or a field you are filling fresh; it inserts at the insertion point, wherever that is.
• Do not position the insertion point with keys to add text: arrow and Meta+arrow presses change nothing you can observe, so they report OUTCOME_UNKNOWN even when they work. On macOS, Home and End only scroll.
• A background app greys out menu commands that act on its front window (Undo, Close, Select All; every command in Chrome, Edge and Electron apps); that is not evidence that a field lacks focus. In continuous-allow mode such a command brings the window forward itself.
• To close a window, click its close button from desktop_observe: it works in the background. If the app then asks about unsaved changes, follow what the user asked for.
• Undo with Meta+Z or desktop_menu_select Edit › Undo, then observe.
• Change only what the task asks. Do not save, close, rename or reformat the user's documents unless they asked; edits stay in the open document.
• After closing a window or quitting an app, OUTCOME_UNKNOWN with reason target-closed-after-dispatch usually means it worked: confirm with desktop_list_windows and never repeat the action.
• Terminals and script apps run whatever reaches them outside the command sandbox. Type exactly what the user asked for — no extra commands, ; chains, redirections or "proof" files. Send Enter with desktop_press, not as a line break inside desktop_type, so the user confirms the text and its execution separately.
• Confirm results from desktop_observe. A terminal's text area shows its newest output (older lines are cut from the top). If typing returns OUTCOME_UNKNOWN, observe first and retry once only if the text is absent. If you still cannot confirm, say so and let the user check.
• Never read an app's content by a side channel: no ⌘A/⌘C into the clipboard, no pbpaste, AppleScript or System Events, no shell history, and no Emperor session or memory files. They overwrite the user's clipboard or reach data the user did not offer.