Adom Bridge

⋯ 1 unchanged line ⋯

@@ -1,6 +1,6 @@ {
   "slug": "adom-bridge",
-  "version": "2.1.159",
+  "version": "2.1.160",
   "type": "app",
   "brief": "Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-only permission system keeps you in charge of every side-effecting command.",
   "description": "Install this package in a cloud or Hydrogen Desktop container, not on the PC. It delivers two things: the Linux adom-bridge-cli (linked onto PATH) and the Claude skill set that teaches an AI every desktop verb (shell, files, screenshots, windows, notifications, KiCad, Fusion 360, browser automation). The CLI drives the Adom Bridge app running on your Windows PC over the relay; the Windows app itself is the separate installer in the Download box, not part of this package. Run adom-wiki pkg update to keep the CLI and skills current.",

@@ -1,6 +1,6 @@ {   "slug": "adom-bridge",-  "version": "2.1.159",+  "version": "2.1.160",   "type": "app",   "description": "Install this package in a cloud or Hydrogen Desktop container, not on the PC. It delivers two things: the Linux adom-bridge-cli (linked onto PATH) and the Claude skill set that teaches an AI every desktop verb (shell, files, screenshots, windows, notifications, KiCad, Fusion 360, browser automation). The CLI drives the Adom Bridge app running on your Windows PC over the relay; the Windows app itself is the separate installer in the Download box, not part of this package. Run adom-wiki pkg update to keep the CLI and skills current.",   "keywords": [

@@ -209,6 +209,7 @@ A verb routed to a bridge that is not up never has to end in a bare timeout. ab 
 - `errorCode:"bridge_installing_deps"`, `stillRunning:true`, `installElapsedSec` - a source-only node bridge's ONE-TIME detached `npm install` is running (minutes on first use). Wait and re-issue the verb; do not restart anything.
 - `errorCode:"bridge_spawn_failed"`, `stillRunning:false`, `lastSpawnError`, `failedAttempts`, `retryBackoffRemainingMs` - the spawn (or its dependency install) failed and ab is in backoff, so it answers immediately instead of re-attempting on every call. `lastSpawnError` is the cause; for an npm failure the real `npm error` lines are in it and the FULL npm output is in `bridge_log_read {"name":"<bridge>"}` -> `npmLog` (also `~/.adom/bridge-logs/<bridge>.npm.log`). Fix the cause, then `bridge_resume {"name":"<bridge>"}` clears the backoff and the next verb retries.
+- `errorCode:"blocked_by_windows_app_control"`, `blockedFile`, `smartAppControl` (`on` | `evaluation` | `off` | `unknown`) - Windows refused to START the bridge's file (2.1.160, wiki #219). On Windows 11 this is almost always Smart App Control blocking an exe that is not code-signed; the user sees a Windows Security notice "Part of this app has been blocked" naming the exe. It is not a crash and retrying cannot help, so ab stops trying (every attempt would show that notice again) and answers this at once. The fix is a signed build from the bridge's author: ab spawns it again by itself as soon as a new file lands, or after `bridge_resume {"name":"<bridge>"}`. `bridge_list` shows the same fields on the bridge's row. Never advise turning Smart App Control off: Windows cannot turn it back on without a reinstall.
 
 `bridge_detail` / `bridge_list` carry the same fields (`lastSpawnError`, `failedAttempts`, `retryBackoffRemainingMs`, `depsInstallingSec`) so you can tell "never tried" from "tried and died" in one read.
 

@@ -71,14 +71,24 @@ When no grant is active, a gated relay call refuses with `errorCode: "needs_appr     "verb": "write_file",
     "grantedBy": "human-only",
     "grantVerb": "request_shell_approval",
-    "howToGrant": ["Ask the user to click Approve (1 hr / 24 hr) or Bypass Permissions ...",
+    "prompt": {"shown": true, "where": "adom_bridge_window",
+               "tellUser": "A dialog and a toast are showing in Adom Bridge on this machine: ..."},
+    "howToGrant": ["Ask the user to approve. A dialog and a toast are showing ...",
                    "Call request_shell_approval to re-surface the prompt ...",
                    "The user can tick Settings > Shell Commands > Bypass Permissions ..."]
   }
 }
 ```
 
-The refusal itself already surfaced a human-facing prompt on the machine: the in-window `#shell-approval` dialog, an actionable Windows toast, and a taskbar flash. If the human actively clicks Deny, you get `errorCode: "denied_by_user"` instead — do NOT auto-retry that one; ask the user what they want.
+**Read `approval.prompt` before you tell the user anything (2.1.160).** It says where the request is right now, and `tellUser` is a sentence you can pass on as-is:
+
+| `prompt` | Meaning |
+|---|---|
+| `shown:true, where:"adom_bridge_window"` | The in-window dialog, an actionable Windows toast and a taskbar flash are up on that machine. |
+| `shown:true, where:"hydrogen"` | ab runs inside Hydrogen and stays hidden; the request is in Hydrogen's permission card / bell. |
+| `shown:false, why:"declined_recently", resumesInSec` | The user declined a prompt in the last 5 minutes, so NOTHING is on screen. Ask them in chat; do not send them looking for a dialog. |
+
+Before 2.1.160 every refusal said a dialog "was just surfaced" in all three cases, which sent users looking for a prompt that was not there (wiki #218). If the human actively clicks Deny, you get `errorCode: "denied_by_user"` instead — do NOT auto-retry that one; ask the user what they want.
 
 ## The correct AI flow on a gate hit