---
title: "Permission prompts in automation: 14 kinds a browser draws"
description: "Why automation cannot see Chrome's permission prompts, which 14 kinds a browser draws beside the page, and which 3 an AI agent should never answer."
canonical: "https://scalebrowser.net/blog/permission-prompts"
last_modified: "2026-10-15"
published: "2026-10-15"
author: "davide"
category: "sign-in"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://scalebrowser.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Permission prompts in automation: 14 kinds a browser draws

> Why automation cannot see Chrome's permission prompts, which 14 kinds a browser draws beside the page, and which 3 an AI agent should never answer.

Your agent clicked "Use my location" and nothing happened. The click was dispatched, the tool reported success, and the page is now waiting for an answer to a bubble that no page map shows. Most automation code never meets this, because it grants permissions in advance or runs where the prompt cancels itself. An agent working real sites for weeks meets it constantly, and it needs to see the question before it can answer it.

## What is a browser permission prompt?

A browser permission prompt is a question the browser draws beside the page, outside the document, when a site asks for something only the person at the machine may grant. Chromium's [permissions component](https://chromium.googlesource.com/chromium/src/+/HEAD/components/permissions/README.md) creates the prompt as its own interface element and reports the person's action back to a request manager, not to the page. Doing nothing is one of the answers.

| Answer | What the site gets | Chromium's rule when it repeats |
| --- | --- | --- |
| Allow | the capability, remembered for the site | none |
| Allow this time | the capability for this visit | clears earlier dismissals |
| Block | a denial, remembered for the site | none |
| Dismiss | a denial for now | 3 dismissals put the site under a 7-day embargo |
| Ignore | no answer at all | 4 ignores put the site under a 7-day embargo |

The embargo numbers come from Chromium's [auto-blocker source](https://github.com/chromium/chromium/blob/main/components/permissions/permission_decision_auto_blocker.cc), where `kDefaultDismissalsBeforeBlock` is 3, `kDefaultIgnoresBeforeBlock` is 4 and `kDefaultEmbargoDays` is 7. A prompt answered wrongly, or dismissed three times, therefore has consequences that outlast the run.

## Which 14 kinds does a browser draw?

A browser draws 14 kinds of permission prompts that an agent can meet, and they fall into three groups by what a wrong answer costs.

- **Machine and money.** Files and folders on the disk, automatic downloads, payments, devices over USB, Bluetooth, serial and HID, and MIDI devices with full control.
- **Watching and listening.** Camera, microphone, location, screen sharing and idle detection, which tells a site when nobody is at the keyboard.
- **Page conveniences.** Notifications, clipboard reading, cross-site storage for an embedded site, and window placement across screens.

The device kinds are pickers rather than yes-or-no questions. A USB, serial or HID prompt lists the real devices attached to the machine, and the answer is a choice from that list. A chat app such as WhatsApp Web can ask for notifications; in 3 signed-out runs on 11 October 2026 no prompt appeared, as WhatsApp Web through an agent records.

## Why can ordinary automation not answer them?

Ordinary automation cannot answer them because it works inside the page, and the prompt is not in the page. The page map comes from the document's accessibility tree, and a click lands in the page's own coordinates, so the bubble can be neither read nor hit. The free path therefore avoids the question: Playwright's [grantPermissions](https://playwright.dev/docs/api/class-browsercontext#browser-context-grant-permissions) sets a permission before the page asks, for a list of names that "may be supported by some browsers".

| Kind | Playwright permission name |
| --- | --- |
| Camera, microphone | `camera`, `microphone` |
| Location | `geolocation` |
| Notifications | `notifications` |
| Clipboard | `clipboard-read` |
| MIDI devices | `midi-sysex` |
| Cross-site storage | `storage-access` |
| Files and folders, automatic downloads, payments | none |
| USB, Bluetooth, serial and HID devices | none |
| Screen sharing, idle detection, window placement | none |

That is 7 of 14 kinds with a name to grant. Pre-granting also changes what the site sees: the answer is yes before the question exists, where a person would often have ignored it or said no. A browser built for an agent has to surface the question instead, which is one of the jobs of [an agent's own browser](/blog/ai-agent-browser).

Without a window the picture splits further. We measured on 10 August 2026 which browser surfaces wait for an answer in a browser that runs without a window: the page's own dialogs such as `alert()` and the device pickers wait indefinitely, while the file picker and the payment sheet cancel themselves and automatic downloads simply proceed.

## How did we check that the agent sees every prompt?

We checked by firing every trigger of [permission.site](https://permission.site/), a public test page with one button per browser capability, and crossing two independent observations for each: what the agent was told, and what state the page gave its own button. A button still waiting while the agent was told nothing is the only real defect, and we call it blind.

<Evidence source="Scalebrowser permission bench against the shipped engine, all 39 triggers of permission.site, 11 August 2026">

| Outcome | Triggers | Meaning |
| --- | --- | --- |
| Seen | 13 | the agent is told, the page still waits |
| Silent | 23 | the page already has its answer, nothing held |
| Blind | 0 | the page waits and the agent is told nothing |
| Unclear | 3 | the page sets no state for these, so the check cannot decide |

</Evidence>

Seeing is half the job, so the answering was measured separately through the agent's own tools on 12 August 2026 on Windows: location allowed, screen sharing dismissed, a USB device picker dismissed and idle detection blocked. Each answer was applied, and afterwards nothing was left open. The [tools page of the documentation](/docs/agents/tools) lists the two tools involved, one to see what the browser is asking and one to answer it.

<ProductMention />

### Which prompts should an agent never answer?

An agent should never answer the 3 kinds whose wrong answer costs something outside the browser: files and folders, automatic downloads and payments. A site granted a folder can read and write it, downloaded files land on the disk without another question, and a payment costs money. These 3 are locked by default and never left to the agent, and the operator can change each of them globally or per profile. Camera and microphone sound more dangerous and stay with the agent, because a profile without a window has no device behind them. The wider picture of what an agent may touch is in AI agent security.
