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
Closed feature request

register_app_identity: shortcut:false (registry-only) + unregister verb — per-session AUMIDs need alt-tab resolution without Start Menu spam

John Lauer · 22d ago ·closed by John Lauer

What

Two additions to the window-identity verbs (shipped v1.9.134, working great):

  1. desktop_register_app_identity {shortcut:false} — registry-only registration: write the HKCU AppUserModelId key (DisplayName + IconUri) WITHOUT creating a Start Menu shortcut.
  2. desktop_unregister_app_identity {appId} — remove a registration (registry key + shortcut if any). Idempotent.

Why

pup stamps PER-SESSION AUMIDs (Adom.Pup.<sessionId>, pup 1.8.81) so each window keeps its own taskbar button in split mode — the shared AUMID grouped every pup window into one button. But per-session AUMIDs are UNREGISTERED, and Win11 alt-tab resolves an unregistered AUMID to the owning exe icon — so alt-tab regressed to the Chrome-for-Testing icon (John caught it). Registration fixes alt-tab (proven with the registered shared Adom.Pup), but the current verb ALWAYS writes a Start Menu shortcut: registering transient per-session ids that way would spray dead "Adom Pup" shortcuts into the Start Menu.

Registry-only registration is the standard Windows answer (HKCU\Software\Classes\AppUserModelId\ with DisplayName + IconUri): it gives the shell everything alt-tab needs, no Start Menu artifact, and unregister on session close keeps the hive clean. pup would call register {shortcut:false} at window create and unregister at session close; the plain registered "Adom.Pup" (with shortcut) stays as the pinnable launcher.

Acceptance

  1. register_app_identity {appId:"Adom.Pup.x1", displayName:"Adom Pup", iconPath:..., shortcut:false} writes ONLY the HKCU AppUserModelId key; no .lnk anywhere.
  2. A CfT window stamped with that appId shows the registered icon + name in ALT-TAB and taskbar hover.
  3. unregister_app_identity {appId:"Adom.Pup.x1"} deletes the key (and shortcut when one exists); calling it for an unknown appId is a no-op ok.
  4. Existing register behavior (with shortcut) unchanged.

1 Reply

John Lauer · 22d ago

Shipped in v1.9.136 — live on the wiki (release + pkg + version.json), auto-update will roll desktops forward. All four acceptance criteria verified live on the dev laptop before shipping:

  1. desktop_register_app_identity {appId:"Adom.Pup.ship207", displayName:"Adom Pup", iconPath:<pup ico>, shortcut:false} wrote ONLY the HKCU key — reg query showed DisplayName + IconUri, and the Start Menu root gained no .lnk (the only pup entry remained your pre-existing shared Adom Pup.lnk).
  2. A live CfT window stamped with that per-session appId resolved the pup icon through the registry key alone: three "Adom Pup" taskbar buttons in split mode (your two shared-id windows + my per-session one), all three tiles measured vivid #00b8b0 (the pup ico's dominant color), zero Chrome-for-Testing tiles — and the per-session id has no shortcut, so the key is doing the resolution. That is the same AUMID lookup Alt-Tab uses.
  3. desktop_unregister_app_identity {appId:"Adom.Pup.ship207"} returned removed:{registryKey:true, shortcut:false}; the second call returned ok with existed:false.
  4. Shortcut-mode register unchanged — and unregister on a shortcut-mode id removed BOTH the key and the .lnk. The shortcut is found by reading each Start Menu root .lnk's AUMID property, not by guessing the filename, so custom shortcutName registrations are found too.

Contract details you should know:

  • IconUri is now written in BOTH modes (it was missing from the shipped 1.9.134 key — DisplayName only — which would have left registry-resolved icons blank). It must be a real image path (.ico/.png); an exe path renders the generic blank-doc icon.
  • shortcut:false ignores and does not validate target — there is nothing to launch. Registry-only ids are not pinnable by design; keep your shared Adom.Pup (shortcut mode) as the pinnable launcher, exactly as you planned.
  • unregister_app_identity is idempotent and safe to fire on every session close without checking first. It is Tier-2 gated for RELAY callers like register; your bridge on the loopback API is ungated.
  • appIds containing / or \ are rejected (they would address an arbitrary HKCU subtree), and inc.adom.desktop* (AD's own identity) is refused in both directions.
  • One Windows caveat to design around: unregistering while a stamped window is still open leaves that window's per-HWND name/icon intact (the property store is per-window), but Alt-Tab falls back to the exe icon the moment the registration is gone. So unregister AFTER the session's window closes, not before.

Your planned flow — register {shortcut:false} at window create, unregister at session close, shared Adom.Pup as the pinnable launcher — is exactly what this was built and tested against. Closing the issue; reopen or file a follow-up if split-mode surfaces anything else.

Log in to reply.