9a96fdc5b8
Live-testing the Cua Driver 0.20 convergence on Windows 11 (session 2, cua-driver 0.20.0) surfaced three defects in the existing-profile browser path and in install status. 1. The config grant was silently nullified by an approval bypass. `--yolo` / `-z` map onto a private unrestricted daemon, which answers every browser_prepare. Because the host delegated the entire existing-profile decision to the driver, that bypass also nullified `computer_use.grant_existing_profile: false`: a plain `hermes -z` attached to the user's real Chrome profile and read live page content over CDP, with the driver reporting it as "the approved existing Chromium profile". It was never approved. An approval bypass is consent to skip prompts, not consent to read an existing profile's pages, cookies, and storage. CuaTypedBrowserRoute.prepare now enforces the key itself, regardless of permission mode. bounded stays exempt - its reviewed capability manifest is the authorization boundary. The authorization inputs are resolved in the backend from config and the backend's immutable mode, never from model-supplied kwargs. 2. The grant, once set, still could not be used. With `grant_existing_profile: true` the runtime is launched `--grant existing-profile` correctly, but cua_browser_prepare then hit a runtime approval prompt anyway - re-asking the user to authorize what the config already authorized, and making the documented opt-in unusable on any non-interactive run, where the prompt has nobody to answer it and the call dies on approval timeout. The durable, file-backed grant now stands in for that prompt. Scope is narrow: only the existing-profile prepare, only when the grant is present; isolated launches still prompt and any resolution failure falls closed to prompting. 3. `computer-use status` hid a custom override and spliced its output. With HERMES_CUA_DRIVER_CMD pointed at cmd.exe, status printed the child's multi-line banner and prompt inside the one-line version field, never mentioned the override, and advised `hermes computer-use install` - which install itself (correctly) refuses to run against an overridden path. It now names the override and mirrors install's update-or-unset guidance, and version output is reduced to one bounded line. Verified on the reported host: `-z` existing-profile attach now refuses and names the key; `grant: true` no longer prompts (33s vs a 300s approval timeout); status names the override and prints one line. No change to the reconciliation path - driver SHA256 unchanged end to end. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>