Adom Hydrogen (platform base)

@@ -1,93 +0,0 @@-----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