Pup - the AI's own browser

@@ -87,6 +87,17 @@ waiting for approval). - **It's a per-box setting.** Some machines have shell auto-approve / Bypass on and show NO popup; others   prompt every time. If a `shell_execute` times out with no result, assume an unapproved popup is waiting —   tell the user to approve it (or enable Bypass/24 hr), then retry.+- **AD ≥ 1.9.86: the prompt auto-surfaces, and you can re-summon it.** Every gate-hit now pops the+  in-window "Shell Command Approval" dialog on the TARGET machine (reliable over RDP) + a toast + a+  taskbar flash — the 1.9.84 regression where a relay caller got `human_only` with NO visible prompt is+  fixed. When a verb returns `errorCode: needs_approval` / `human_only`:+  1. `adom-desktop --target <box> request_shell_approval` — re-surfaces the dialog AND foregrounds AD+     (use it when the user says "I see nothing to click"; it only surfaces, never grants; if a grant is+     already active it tells you so — just run your command).+  2. Ask the user to click **Approve 1hr / 24hr / Bypass** in the AD window on that box.+  3. **RETRY your original verb.** Do NOT call `shell_auto_approve` — it is human-only and refuses;+     granting happens only in AD's UI (Settings → Shell Commands, the footer +1hr/+24hr/Bypass bar,+     the dialog, or the toast). - **This is NOT a UAC.** The shell-approval dialog is AD's own permission gate (safe to approve for your   setup commands); a Windows UAC is the separate admin-elevation prompt (e.g. the Node MSI). 

@@ -1,6 +1,6 @@ {   "slug": "adom-desktop-puppeteer-bridge",-  "version": "1.8.16",+  "version": "1.8.17",   "type": "app",   "description": "CONTAINER-SIDE install \u2014 the pup skill pack in the wiki skillpack layout: the everyday `pup` user skill PLUS two bundled developer sub-skills (pup-bridge-dev, pup-bridge-publish; user-invocable:false, DEVELOPER-only descriptions so they never trigger for everyday users), all dropped into ~/.claude/skills/ AND ~/.codex/skills/ by an explicit install.sh list. It does NOT contain the bridge runtime: the bridge (Node + browser driving) lives on the DESKTOP \u2014 bundled inside Adom Desktop and published on the Releases tab as adom-bridge-puppeteer-v<ver>.zip, which Adom Desktop streams into its bridges-cache. TL;DR: pkg install = the skill pack; the bridge = the Release zip + bundled in Adom Desktop.",   "keywords": [

@@ -170,6 +170,12 @@ What we learned and baked into the code:   showed nothing). Two consequences baked into SKILL.md: (1) prefer core/`browser_*` verbs over shell;   (2) before any `shell_execute`, `notify_user` the person to approve the popup. This is a separate gate   from the Windows UAC (admin elevation) — don't conflate them.+  **AD ≥ 1.9.86 addendum:** every gate-hit now auto-surfaces the in-window approval dialog + toast ++  taskbar flash on the target box (1.9.84 briefly regressed to a silent `human_only` refusal with NO+  prompt — bricked shell on headless/RDP boxes). On `needs_approval`/`human_only`: run+  `adom-desktop --target <box> request_shell_approval` (re-surfaces the dialog + foregrounds AD;+  surfaces only, never grants), have the human click Approve/Bypass, then RETRY the original verb.+  Never call `shell_auto_approve` — it's human-only and refuses by design. - **Windows Firewall prompt = bind loopback (fixed v1.6.0).** A hostless `server.listen(PORT)` binds ALL   interfaces (0.0.0.0), so Windows pops "Allow Node.js through the firewall (public/private)?" on first   listen — a THIRD scary prompt after UAC + shell-approval, and worse on a fresh portable-node path the