app

Adom Bridge

Public Made by Adom

by adom

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-onl

adom-bridgetauriclaude-codebridgekicadfusion360puppeteerdesktop-automation
Overview Files Skills Discover Packages Releases Dependencies Issues40 Breadcrumbs Pull Requests Activity
Open general

Shell-approval toast must show the full command + args, not just 'powershell' (moved from hydrogen-desktop#8)

John Lauer · 7d ago

Type: Bug (moved from adom/hydrogen-desktop#8, filed by kaleymer)

The shell-approval toast shows only the bare program name ("powershell"), never the args or -Command payload that determine what actually runs. A user is asked to grant 1h/24h approval with zero visibility into the command, so responsible users deny everything and are blocked.

Since approvals moved into AD (>= 1.9.191), HD only mirrors AD's toast, so this fix lives here now:

  1. Show the full command + args in the approval toast/dialog (truncated preview + expandable details for long payloads).
  2. Make explicit what a 1h/24h grant covers (any invocation of that interpreter vs the specific command); ideally scope the time-boxed grants to the specific command.

Original report with repro: https://wiki.adom.inc/adom/hydrogen-desktop (issue #8, now closed as moved).

2 Replies

John Lauer · 7d ago

Fixed in AD 1.9.219 (commit 8002648), both asks:

  1. The per-command approval toast now shows a 220-character command preview (was: 60 chars, which on a powershell -Command invocation left little more than the word 'powershell') plus the AI's stated reason, attributed ('The AI says: ...'), in the toast body. The in-window approval dialog always carried the FULL command in its 

     block and still does - the toast is the summary, the dialog is ground truth.

  2. Grant scope is now visible text in the approval dialog, not just button hover-tooltips: 'Approve once and Deny apply to this command only. Approve 1 hr / 24 hr / Bypass auto-approve ALL shell and system commands on this machine until they expire or you revoke.' That is an honest description of the current model (the time-boxed grants are class-wide, not per-command). Scoping timed grants to a SPECIFIC command is a real design change to the permission model and deliberately not part of this fix; if kaleymer wants it, it should be its own issue so the trade-offs (grant explosion vs precision) get discussed on their own.

John Lauer · 1d ago

Fixed in 2.0.11. shell_execute already showed the full command (v1.9.219); the gap was every OTHER gated verb — run_script, wsl_exec, wsl_verb, the generic Tier-2 gate — which surfaced through surface_shell_permission_request with only the verb name. That function now takes a detail param; run_script and wsl_exec pass the decoded script preview, so the toast body AND the in-window dialog show the actual command/script (truncated to 300 chars), not just the interpreter name. Generic gates (request_shell_approval, the bare Tier-2 surface) pass None and keep the generic wording, since there's no single command behind them.

Log in to reply.