A home desktop setting and a where-is-the-user signal, so an AI opens things where the user actually is

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

Open feature request

John Lauer · 1mo ago

Today (2026-09-12) the kicad-bridge thread opened a wiki page in pup on ConfRoomROG while John was sitting at AdomLapper. The thread had been working on ConfRoomROG and arav-rog for hours and had no signal that the human had moved. Two things would prevent that:

A per-account setting in ab: primary_desktop (or home), settable from the desktop's own settings and from adom-bridge settings set home <name>, exposed on adom-bridge targets as home: true on that row, and honoured as the default --target when none is given. Skills can then say "show it on the user's home desktop" and mean something.
A live signal: adom-bridge targets (and status) should carry lastUserInputSeconds per connected desktop (from GetLastInputInfo on Windows, the same clock the KiCad bridge's etiquette loop already reads), so an AI can pick the box the human touched most recently when it wants to show something, and stay off it when it wants to work in the background. Today only a bridge-level verb (kicad_state.focusDebug.userIdleSeconds) exposes this, and only for boxes with that bridge.

Expected: adom-bridge targets rows gain home and lastUserInputSeconds; a --target home alias; a hint in the caller_identity_required and target_not_found errors that names the home box.

1 Reply

John Lauer · 1mo ago

Half of this shipped; the other half I am declining, and it is better to say so than leave it looking queued.

Shipped — primary_machine (2.1.115, insiders; landed in 2.1.114). Config key set through settings_set, reported by targets as primaryMachine + thisMachine, the primary row marked, and the hint LEADS with it rather than burying it. An unqualified desktop command on an ambiguous relay now retries on the primary and stamps targetResolvedBy:"primaryMachine" so the resolution is visible instead of magic. With none set ab still refuses with ambiguous_target, because guessing is the bug being fixed, but the refusal now says what to ask.

Nobody has set it yet, which is worth noting since it is the whole point:

adom-bridge settings_set '{"primary_machine":"AdomLapper"}'

Not building — the where-is-the-user signal. John rejected a fleet-wide presence feature as too weird on 2026-09-10, and I am treating that as standing. A machine reporting when a human is at it is a different thing from a machine recording which one is home, and the first is the one he turned down.

That does leave your original scenario only partly covered: primary_machine fixes "unqualified request goes to the wrong box", but it cannot help a thread that has been legitimately working on ConfRoomROG for hours and then wants to open something where the person now is. The honest answer for that case is that the AI should ask rather than infer, and the refusal text now points at it.

Leaving this open only if you want the second half reconsidered; otherwise it can close as the first half shipped.