# adom-desktop feature request: auto-grant `automatic_downloads` on every pup `browser_open_window`

Paste into Claude on the desktop.

## TL;DR — the simple, primary ask

**Bake `automatic_downloads: granted` for ALL origins into every `browser_open_window` call by default.** That's the single fix that solves 95% of the chip-fetcher pain. Use Chromium's CDP `Browser.grantPermissions` at session creation:

```js
// In adom-desktop's puppeteer-side session bootstrap, right after browser launch:
await browser._client().send('Browser.grantPermissions', {
  permissions: ['automaticDownloads', 'notifications', 'clipboardReadWrite']
  // origin omitted = applies to all origins
});
```

This means: chip-fetcher (and every other pup-driven flow) never has to deal with the "<site> wants to Download multiple files / Allow / Block" dialog. The user clicks once, multiple downloads in sequence Just Work, and the agent doesn't need to know the dialog ever existed.

Direct user request: *"can you just always give that always allow for multiple downloads anytime you open a pup window for chip-fetcher so we never have that issue in the future?"*

Add an opt-out via `browser_open_window` arg if a session ever needs strict mode:

```bash
adom-desktop browser_open_window '{
  "sessionId":"some-strict-session",
  "url":"...",
  "strictPermissions": true
}'
```

Default behavior (no arg or `strictPermissions: false`): permissive. That's what 100% of chip-fetcher's flows want.

---

The rest of this doc is a longer-form spec covering other dialog types and detection APIs — useful if you want a more complete browser-permissions feature, but the **TL;DR fix above unblocks chip-fetcher today**.

## Background

## Background

`browser_input_dispatch` (v1.4.7+) lets the agent fire trusted clicks at page-level DOM elements. But Chromium has a layer ABOVE the rendered page — its own browser-chrome permission dialogs — that isn't reachable via `Input.dispatchMouseEvent` because those clicks resolve in DOM coords against the page, not against the Chromium UI shell.

Common dialogs that the agent CAN'T see or click today:

- **"<site> wants to Download multiple files / Allow / Block"** — fires on the second-or-later download per origin per session. Verified blocking on `componentsearchengine.com` and `snapeda.com` flows when the agent fires multiple format-downloads in sequence.
- **"<site> wants to: Show notifications / Use your camera / Use your microphone"** — vendor sign-up flows sometimes trigger.
- **"Open in <Application>?"** — when a download triggers an OS-level handoff (e.g. .step files associated with a CAD tool).

The user has no programmatic way to know these dialogs appeared, and the agent can't dismiss them. Today: the user has to look at the pup window, click Allow, then tell the agent to retry.

## What I want

### Item 1 — `browser_list_chrome_dialogs`

Surface Chromium's dialog state. Use Puppeteer's `page._client().on('Page.javascriptDialogOpening', ...)` and `Browser.cdpSession` listeners for browser-level prompts.

```bash
adom-desktop browser_list_chrome_dialogs '{"sessionId":"chip-fetcher"}'
# returns:
{
  "dialogs": [
    {
      "type": "permission",
      "permission": "download_multiple_files",
      "origin": "https://www.snapeda.com",
      "message": "snapeda.com wants to Download multiple files",
      "options": ["Allow", "Block"],
      "dialogId": "perm-1"
    }
  ]
}
```

### Item 2 — `browser_dismiss_chrome_dialog`

```bash
adom-desktop browser_dismiss_chrome_dialog '{
  "sessionId":"chip-fetcher",
  "dialogId":"perm-1",
  "action":"Allow"
}'
# returns: {ok: true, dismissed: "perm-1"}
```

Permissive by default for the chip-fetcher use case (`Allow`); the chip-fetcher SKILL.md already documents that we want multi-download permission auto-accepted on every CSE/SnapEDA/UL flow.

### Item 3 — `browser_set_default_permission`

Pre-grant permissions per-origin so the dialog never fires:

```bash
adom-desktop browser_set_default_permission '{
  "sessionId":"chip-fetcher",
  "origin":"https://www.snapeda.com",
  "permission":"automatic_downloads",
  "value":"granted"
}'
```

Maps to Chromium's `Browser.setPermission` CDP method. This is the cleanest fix — set it once during `browser_open_window` and never see the dialog again.

### Suggested defaults baked into the bridge

When a session is created, auto-grant on common origins:

```json
[
  "componentsearchengine.com",
  "*.componentsearchengine.com",
  "vendor.ultralibrarian.com",
  "snapeda.com",
  "www.snapeda.com",
  "www.mouser.com",
  "www.digikey.com",
  "www.ti.com",
  "www.nordicsemi.com",
  "www.nxp.com",
  "www.st.com"
]
```

with `automatic_downloads: granted`. Add a `disable_default_permissions: true` arg for `browser_open_window` if a session needs strict mode.

## Verification

After ship, this WAGO/CSE/SnapEDA recipe should run without any user interaction at the multi-file Allow step:

```bash
adom-desktop browser_open_window '{"sessionId":"x","profile":"x","url":"https://www.snapeda.com/parts/<MPN>/.../view-part/"}'
# (no manual Allow click required even on the second per-part-format download)
adom-desktop browser_input_dispatch '{"sessionId":"x","type":"click","selector":"#download_step_model"}'
sleep 3
adom-desktop browser_input_dispatch '{"sessionId":"x","type":"click","selector":"#download_kicad"}'
# Both downloads land without the Allow dialog ever firing
```

— sent from john's container running chip-fetcher v0.1.x against adom-desktop v1.4.11