control-in-app-browser

Explicitly request the in-app, right-side, or current Browser in your message, and the agent loads this skill and uses the native browser tool. It inspects the page first, then acts through opaque element refs one action at a time.

The inspect action returns actionable elements with opaque refs, and truncated results include a continuation with snapshotId and offset. The agent copies that continuation unchanged to page through the same snapshot instead of restarting inspection.

Yes, upload_files accepts exact paths from current-turn attachments or regular files inside the active workspace. The action itself validates existence, type, authorization, count, and size, so no separate filesystem preflight is performed.

No, the agent never reads or types credentials, codes, or CAPTCHAs. On a visible provider it pauses with ask_user so you take over the same tab; a headless provider without a takeover surface stops and reports that interactive login is required.

When a linked resource has a purpose-built skill, connector, API, or CLI that can perform the operation, that path is preferred. The browser is used only when no such path exists, lacks the capability, or you explicitly request the in-app Browser.

Final publish, send, submit, delete, purchase, or account-change actions require explicit confirmation immediately before execution. The agent prepares the draft, states the exact action and content, and waits for your approval via ask_user.