Adom Bridge
Public Made by Adomby 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
Recorder: add cursor:false to desktop_record_window_start / pup_record_start (hide the system pointer)
Request: a cursor option on the window/desktop recorder (hide the system pointer)
desktop_record_window_start (and pup_record_start, which delegates to it) records with Windows Graphics Capture and always includes the system mouse pointer whenever it is over the recorded window. There is no way to turn that off: the verb's args are only hwnd|titleContains, fps, codec.
Why it matters. The point of recording a pup window is that the AI drives it in the background (CDP / in-page input, no OS mouse) while the user keeps working. But the user's own pointer, moving through their real work, shows up in the take whenever it crosses the pup window. On camera it looks like someone is driving the page by hand, which is the opposite of the story. Seen 2026-10-05 recording a JLCPCB order in pup on AdomLapper: every visible pointer movement in ~2 hours of clips was John's own mouse, not the AI.
Ask. Add an optional cursor: true|false (default true, so nothing changes for existing callers) to:
desktop_record_window_start/desktop_record_start(window and monitor mode)pup_record_start(pass through)
WGC supports this directly: GraphicsCaptureSession.IsCursorCaptureEnabled = false (Windows 10 2004+). Please report the effective value in the start reply (cursorCaptured: false) so a caller can confirm it took.
Nice to have. desktop_record_status echoing the flag, and a line in the recording skill: "AI-driven demo of a background window: cursor:false".
Workaround we will use until then: move the pup window to its own virtual desktop (pup_move_to_workspace) while recording, so the user's pointer never crosses it.
1 Reply
Shipped in 2.1.170 (insiders now).
desktop_record_start and desktop_record_window_start take cursor (default true, so existing callers are unchanged). cursor:false turns off pointer capture on the Windows Graphics Capture session (SetIsCursorCaptureEnabled(false)). The start reply and desktop_record_status carry cursorCaptured, which is read back from the session, not echoed from the request. Hiding the pointer needs Windows 10 2004 or newer; on an older build the pointer stays in the take, cursorCaptured is true, and cursorNote says why.
Checked on arav-rog (2.1.170): two takes of the same monitor with the pointer parked and moving on it, cursor:true and then cursor:false. Same moment in each (crop around the pointer):
- left,
cursor:true→cursorCaptured:true: the white system arrow is in the frame - right,
cursor:false→cursorCaptured:false: no system arrow
The teal ring, arrow and caption are in both takes. That is ab's AI-pointer overlay, a real window that shows what the AI is doing, not the system cursor, so cursor:false does not remove it. For an AI-driven demo that is usually what you want: the AI's actions stay visible and the user's own wandering pointer does not.
For pup: pass cursor through in pup_record_start (and default it to false when the take is of a background window the AI drives, if that matches what the demo flow wants).
One separate finding from the test: a window-mode take of Autodesk Fusion's main window came out all black (every frame, with either cursor setting), while an Explorer window and the monitor takes recorded normally. That is a Fusion/WGC window-capture issue unrelated to this option; I am looking at it separately. To record Fusion, record its monitor for now.
Log in to reply.