Adom-branded overlay next to the REAL OS cursor when AD drives the mouse (desktop_click/hover) — trust/attribution - Adom Bridge

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

Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity

Closed feature request

Adom-branded overlay next to the REAL OS cursor when AD drives the mouse (desktop_click/hover) — trust/attribution

John Lauer · 3mo ago ·closed by John Lauer

Request: an Adom-branded overlay next to the REAL OS cursor whenever AD drives the mouse

Why (from John): when AD moves and clicks the real Windows cursor (via desktop_click / desktop_hover), the user should be able to tell at a glance that Adom is controlling their mouse — not Claude's browser extension, not malware, not a stuck cursor. Right now the OS cursor moves with zero attribution. This is a trust/safety feature: a user watching their mouse move on its own needs to know it's their Adom agent doing authorized work.

This came up doing real work: AD's desktop_hover-then-desktop_click is the ONLY thing that can drive Google's FedCM "Sign in with Google" account chooser (every in-page/CDP/UIA click is rejected), and it will be used heavily for hours-long autonomous tasks (e.g. downloading electronics libraries, clicking native Save-As dialogs). Users need persistent visible attribution during that.

What pup already did (the in-page half): the pup bridge (v1.9.164/165) injects a teal Adom cursor with a small Adom orbital badge for its in-page CDP clicks. But that only works inside a web page pup controls — it can't render over native dialogs, the taskbar, cross-origin FedCM iframes, or anything outside the DOM. The OS-level overlay is AD's to own because AD owns the SendInput path.

Proposed: a small always-on-top, click-through (WS_EX_LAYERED | WS_EX_TRANSPARENT | WS_EX_NOACTIVATE) overlay window that:

Shows the Adom logomark (teal 2p-orbital mark) pinned just off the cursor hotspot (e.g. bottom-right, ~16px), following the cursor whenever an AD-driven move/click is in flight.
Optionally a brief label/toast on the FIRST action of a burst: "Adom is controlling your mouse — <thread name / reason>" (the caller identity AD already has), then quiets to just the badge.
Appears only while AD is actively driving (a move/click within the last N seconds), auto-hides when idle so it never clutters normal use.
Respects the same foreground-etiquette AD already enforces (the badge is the visible consent signal the user sees when a window is foregrounded for a real click).

Nice-to-have: a subtle glide animation on the cursor move (like the pup in-page cursor and the nbrowser extension's animated cursor) so the motion reads as deliberate agent action, not a glitch.

Filed from the pup bridge maintainer thread; pup will link its in-page cursor to this so the two are visually consistent (same Adom mark) once AD ships the OS overlay.

1 Reply

John Lauer · 2mo ago

Shipped. The branded cursor has been in since v1.8.171 and got finished properly in 2.0.84, which is when it became something a user actually sees by default.

What it does now, when ab drives the real OS mouse (desktop_click / double_click / right_click / hover / move, and their new mouse_* aliases):

A teal Adom pointer glides to the target before the real click, so the motion is attributed rather than a bare cursor jump.
It carries the actual Adom favicon as a badge, positioned clear of the pointer tail.
A floaty teal glow breathes around it (the same visual language as Hydrogen's setup steps).
A label reads <AI thread>: <reason> - so it names not just "Adom" but which of the user's ~20 threads is driving and what it is trying to do. Takeover verbs now REQUIRE a reason from a relay caller for exactly this purpose.
On by default as of 2.0.84. It was opt-in (cursor:true), which meant the attribution was absent precisely when a caller was careless - the case it exists for. Pass cursor:false to suppress; pass label:"..." to narrate in your own words.
Auto-hides, and is click-through, so it never blocks the click it narrates.

Your hours-long-autonomous-task case is the one that drove the default flip: over a long unattended run the user should never have to wonder who is moving their mouse.

One thing your report asked for that is deliberately not there: the cursor does not appear for background UIA actions (desktop_ui_click etc.), because those do not move the pointer or steal focus - there is nothing for the user to be startled by. It is scoped to real OS input.

John Lauer closed this · 2mo ago