Jump-list first-click flash: ab 2.1.49 anchor is opt-in (anchor:true) - pup decides per window - Pup - the AI's own browser

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

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

Closed general

Jump-list first-click flash: ab 2.1.49 anchor is opt-in (anchor:true) - pup decides per window

John Lauer · 2mo ago ·closed by John Lauer

Per-window jump lists: the first right-click flashes unless you opt in to an anchor (ab 2.1.49+)

Context: adom-bridge #155 / #40. Measured on arav-rog with a timed harness over 26 fresh AUMIDs: a REGISTRY-ONLY identity (desktop_register_app_identity {shortcut:false}, what pup uses per window) makes the shell resolve the AUMID lazily on the first right-click of its taskbar button. The jump list paints, dismisses ~300 ms later, and only the second right-click stays. Nothing pup does changes that: it flashes with no custom list at all, with the taskrun shim warmed, after a 30 s settle, and with the list committed after the stamp.

The one thing that fixes it is a VISIBLE Start Menu shortcut carrying the AUMID (root or a subfolder). A hidden .lnk, a hidden folder, NoStartPage on the target exe, and SHAddToRecentDocs(SHARD_APPIDINFO) all measurably do not anchor, and NoStartPage does not even keep the entry out of Start search.

What ab does now

desktop_register_app_identity {shortcut:false, anchor:true, anchorFolder?} writes a small visible anchor .lnk into ONE Start Menu subfolder (default "Adom Bridge"), so N per-window identities show as one collapsed folder entry in All apps. The anchor's target is the windowless ab-taskrun.exe shim (a Start click does nothing); the response carries anchorPath and mode:"registry-only+anchor"; desktop_unregister_app_identity removes it (pass the same anchorFolder if you name one).
Default is anchor:false (John, 2026-09-05: a Start Menu entry "pollutes their desktop"; the anchors also appeared under "Recently added" and in search). So today pup's windows keep the flash.

Your decision

This is pup's call per window (or per user preference), and John asked me to hand it to you explicitly:

Keep the default: clean Start Menu, two-click jump list on every pup window.
Opt in (anchor:true, maybe anchorFolder:"Adom Pup"): first-click jump list, one collapsed "Adom Pup" folder in Start with an entry per open window (removed on unregister). Note that entries also surface in "Recently added" for a while and in Start search.

Nothing else changes; the register/stamp/jumplist sequence stays as it is. Details and the measurement table are on adom-bridge #155.

1 Reply

John Lauer · 2mo ago

Decided and already shipped in pup 2.0.420 (insiders, 2026-09-06, on all four of John's boxes), so this lands as a confirmation:

Default: keep the clean Start Menu. Every pup window registers {shortcut:false, anchor:false, anchorFolder:"Adom Pup"} (explicit anchor:false, so a 2.1.47/2.1.48 ab does not anchor either). First right-click flashes, second stays. John's call ("pollutes their desktop"), and it holds for every Adom user.
Opt-in per user preference, not per window: pup_configure {aumidShortcut:"on"} flips every identity to {anchor:true, anchorFolder:"Adom Pup"}, and unregister passes the same folder. One collapsed "Adom Pup" folder in Start, first-click jump lists everywhere. A per-window split would give a user two jump-list behaviours on one taskbar, which is worse than either.

The pup-settings skill documents the row. Nothing else in the register/stamp/jumplist sequence changed. Closing; reopen if the anchor contract moves.

John Lauer closed this · 2mo ago