// PermissionRequested: auto-grant EVERY permission kind (clipboard
// read, mic, camera, geolocation, notifications, sensors, …) so the
// user never sees a WebView2 "site wants to" dialog.
…
args.SetState(COREWEBVIEW2_PERMISSION_STATE_ALLOW)?;
hd_log::hd_log!("[perm] auto-granted permission kind {:?}", kind);

---
name: hd-permissions
description: >
  Hydrogen Desktop AUTO-GRANTS every WebView2 permission — microphone, camera,
  clipboard-read, geolocation, notifications, sensors — so inside HD a webview
  app NEVER shows a "this site wants to use your microphone/camera/clipboard/
  location" prompt. READ THIS before building or debugging a webview app that
  uses getUserMedia / clipboard / geolocation: do NOT tell the user to click
  "Allow" — there is no prompt to click; it's suppressed by design. Distinguish
  this browser-permission auto-grant from the SEPARATE in-app screen-share / mic
  consent the AI itself requests (that one IS user-approved — see hd-capture-
  share). Trigger words — permission, permissions, webview2 permission, allow
  microphone, allow camera, allow clipboard, clipboard read, getUserMedia, mic
  permission, camera permission, geolocation permission, notifications
  permission, sensors permission, site wants to use, permission prompt, click
  allow, no permission prompt, auto-grant, auto granted, why no prompt,
  permission denied webview.
---

# HD auto-grants every WebView2 permission

Hydrogen Desktop's webview (Windows / WebView2) registers a
`PermissionRequested` handler that returns **ALLOW for every permission kind** —
microphone, camera, clipboard-read, geolocation, notifications, sensors, etc. So
**inside HD the user never sees a "this site wants to use your microphone /
camera / clipboard / location" dialog.** Webview apps that call `getUserMedia`,
read the clipboard, or ask for geolocation simply *work*, with no prompt.

Evidence: `hd-app/src/lib.rs` (~lines 326-349):

```rust
// PermissionRequested: auto-grant EVERY permission kind (clipboard
// read, mic, camera, geolocation, notifications, sensors, …) so the
// user never sees a WebView2 "site wants to" dialog.
…
args.SetState(COREWEBVIEW2_PERMISSION_STATE_ALLOW)?;
hd_log::hd_log!("[perm] auto-granted permission kind {:?}", kind);
```

Every request is unconditionally set to `COREWEBVIEW2_PERMISSION_STATE_ALLOW`. In
the HD log you'll see lines like `[perm] auto-granted permission kind …` and, at
startup, `[perm] Registered PermissionRequested auto-grant handler`.

## Why HD does this

HD is the user's **trusted desktop app** — they've already chosen to run it.
Intermediate per-site Web permission prompts (especially the clipboard-paste
dialog) are pure friction with no added safety here, since there's no untrusted
third-party browsing context: the surfaces are HD's own panels and the user's own
webview apps. So HD grants them all up front.

## What this means for you when building webview apps

- **Don't instruct the user to "click Allow."** There is no prompt — telling them
  to look for one is wrong and confusing. `getUserMedia({ audio: true })`,
  clipboard reads, geolocation, notifications all resolve without a dialog.
- If a webview app *isn't* getting mic/camera data, the cause is **not** a denied
  permission prompt (HD never denies). Look elsewhere: no device present, the
  page served over a non-secure context, a code bug, or the OS-level Windows
  privacy toggle for the camera/mic being off for the app entirely.
- This is WebView2/Windows-specific behavior baked into HD's webview host — it's
  not something the web page or the user configures.

## NOT the same as in-app screen-share / mic consent

This auto-grant is **only** the low-level WebView2 browser-permission layer.
It is separate from the **screen-share / microphone consent the AI itself
requests** when it wants to capture the user's screen or mic for a session — that
flow **is** explicitly user-approved (the user sees and accepts an in-app consent
UI). Don't conflate them: WebView2 site permissions are silently allowed; the AI's
capture/share request is a real, user-facing approval. See `hd-capture-share`.

## Third layer: the SHELL/COMMAND approval gate (embedded AD, 2026-07)

Distinct from both layers above: when HD embeds Adom Desktop, **gated AD
commands** (shell_execute, run_script, write_file, ...) forward their approval
to HD's permission dialog. Facts an agent must know:

- **Grants are HUMAN-ONLY by design.** No API self-approves; `/permission/resolve`
  is de-escalation only. Never attempt to grant yourself permissions.
- The request surfaces as HD's in-app dialog AND an **AD toast that is a real
  decision surface** (same Approve 1 hr / 24 hr / Bypass buttons + the requester's
  reason; clicking the toast resolves the request) — so approval works even when
  HD isn't foreground.
- **Time-based grants persist across HD restarts** (0.1.253+): an "Approve 24 hr"
  survives an app update mid-window.
- Requests **fail closed** at ~60s if the human doesn't respond; the requester's
  stated reason is always rendered ATTRIBUTED ("caller says: ..."), never as fact.

## Related skills
- `hd-capture-share` — the SEPARATE, user-approved screen-share / mic consent the AI requests
- [hd-open-url](../hd-open-url/SKILL.md) — opening URLs/webview apps inside HD (where these permissions apply)
- [hd-browser-picker](../hd-browser-picker/SKILL.md) — routing URLs to webviews vs native browsers vs Pup