app

Adom Chip Fetcher

Public Made by Adom

by adom

Your whole parts library — manufacturer-grade chip CAD (symbol, footprint, 3D) one tap from your EDA tool.

edacadpartscomponentspcbcli
Overview Files Skills Discover Packages Releases Dependencies Issues1 Breadcrumbs Pull Requests Activity
adom-chip-fetcher / scripts / adom-desktop-chrome-permissions-prompt.md
Download

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:

// 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 " 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:

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:

  • " 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.
  • " wants to: Show notifications / Use your camera / Use your microphone" — vendor sign-up flows sometimes trigger.
  • "Open in ?" — 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.

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

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:

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:

[
  "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:

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