Accounts & Sign-in

Agents act in your signed-in Chrome, so they can do anything you can. chrome-use checks every action against the site it lands on: sensitive sites and risky actions stop and wait for you. The check runs in the CLI and leaves nothing a page can see.

When chrome-use asks first

While it drives your own Chrome through the extension, the first three wait for your decision by default; the last three are off until you turn them on:

The detection is heuristic. Typing without a ref or selector (focus, then keyboard type) or a pay button with an unusual name can slip through. It is a gate for a person to look, not a sandbox.

--launch and --cdp sessions do not get these defaults (usually nobody is watching there). They follow your policy file only.

Approving

A gated command does not run. It exits with code 3 and prints a confirmation id:

$ chrome-use click @e7
Confirmation required:
  click: www.chase.com is a banking or payments site; chrome-use asks before an agent acts there (click)
  Site: www.chase.com
  Ask the user to choose Allow once, Always allow on this site, or Decline
  in the chrome-use side panel or its notification. Then:
  Run: chrome-use confirm s_3f9a0c2b1d   (waits up to 40s for the choice)
  Or:  chrome-use deny s_3f9a0c2b1d

Chrome shows a notification, and a card appears in the side panel and under "Permissions & safety" on the options page with three choices: Allow once, Always allow on this site and Decline. When the agent runs chrome-use confirm <id>, it waits up to 40 seconds for your choice and runs the original command if you allowed it.

Only you can approve in the extension: the agent running confirm does not let the action through. chrome-use deny <id> withdraws the request.

With --confirm-interactive at a terminal, the prompt becomes [y]es once / [a]lways on this site / [N]o. "always" lands in the extension's approved-sites list.

Without the extension (--launch, --cdp) or with an extension older than 0.5.93, confirm <id> approves directly, as with --confirm-actions.

Approved sites and permission history

The "Permissions & safety" card on the extension's options page lets you:

• turn the sensitive-site list on or off, and pick which actions always ask (payment card fields and purchases, plus password fields and downloads, which are off by default) and which categories ask the first time on a new site;
• see, add and remove approved and blocked sites (an agent may not act on a blocked site at all);
• read the last 200 permission events: each choice, requests the agent withdrew, and list changes.

Turning the defaults off or extending them

• Options page: turn off "Ask first on sensitive sites", or untick an item under "Always ask before".
• Environment: CHROME_USE_SENSITIVE_SITES=0 turns off the sensitive-site list (not when an organization policy pins it).
• The sites block of an --action-policy file:

{
  "deny": [],
  "sites": {
    "allow": ["intranet.example.com"],
    "deny": ["evil.example"],
    "confirm": ["payroll.example.com"],
    "sensitiveSites": true,
    "firstVisit": ["navigation", "upload"],
    "ask": ["payment_input", "purchase", "download"]
  }
}

allow skips asking, deny refuses, confirm puts a site on the ask-first list. sensitiveSites, firstVisit and ask mean the same as on the options page. A policy file's sites also applies to --launch and --cdp sessions. To add a site to the built-in list, open a PR against sensitive_sites.json.

Precedence, highest first: organization policy, your choices in the extension, the policy file, built-in defaults. A block always beats an allow, and the always-ask actions still ask on allowed sites.

Managed by an organization (Chrome enterprise policy)

The extension reads chrome.storage.managed (its manifest declares managed-schema.json). Values an administrator sets override the user's, and the options page shows them as "Managed" and read-only.

Chrome policy JSON for Windows and Linux (on Linux, in /etc/opt/chrome/policies/managed/):

{
  "3rdparty": {
    "extensions": {
      "ciiljdlhdpfckdcfkphgmfalanpdejep": {
        "allowedDomains": ["example.com", "corp.example.com"],
        "blockedDomains": ["mail.example.com"],
        "confirmDomains": ["payroll.example.com"],
        "sensitiveSites": true,
        "ask": ["payment_input", "purchase", "download"],
        "actionPolicy": { "deny": ["upload", "eval"], "confirm": ["download_url"] },
        "disabledAgents": ["opencode"]
      }
    }
  }
}

A macOS .mobileconfig fragment (goes in the PayloadContent array):

<dict>
  <key>PayloadType</key>
  <string>com.google.Chrome.extensions.ciiljdlhdpfckdcfkphgmfalanpdejep</string>
  <key>PayloadIdentifier</key>
  <string>com.example.chrome-use.policy</string>
  <key>PayloadUUID</key>
  <string>9A6E0C1E-0000-4000-8000-000000000781</string>
  <key>PayloadVersion</key>
  <integer>1</integer>
  <key>allowedDomains</key>
  <array><string>example.com</string><string>corp.example.com</string></array>
  <key>blockedDomains</key>
  <array><string>mail.example.com</string></array>
  <key>sensitiveSites</key>
  <true/>
  <key>actionPolicy</key>
  <dict>
    <key>deny</key>
    <array><string>upload</string></array>
  </dict>
  <key>disabledAgents</key>
  <array><string>opencode</string></array>
</dict>

Use the extension id of the build you deploy: the one above is the self-signed build's id; the Chrome Web Store build has its own. chrome://policy shows whether the policy took effect.

Under stealth mode

Every check runs in the CLI daemon. The site comes from the command's URL or the page address the daemon already tracks; whether a field is sensitive is read with CDP DOM.describeNode, so no script runs in the page. The approval UI lives in the extension's own pages (side panel, options page, notification). A page sees no new globals, DOM nodes, events or requests, and stealth mode is unaffected.