pup_progress paints nothing through windowTarget while a direct desktop_taskbar by hwnd paints fine

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

John Lauer · 2mo ago ·closed by John Lauer

Evidence pair in shotlog channel crr-pup-test (PROGRESS BUG EVIDENCE A/B, 2026-08-16): calling desktop_taskbar directly with the session window's hwnd renders the Win11 progress underline on the thread-tile button; the pup_progress verb path (2.0.195, which resolves the hwnd via resolveSessionHwndByBounds then targets via windowTarget) leaves the pill gray in the same conditions, including steady state. So windowTarget is returning something the paint cannot land on for this session (stale/validated-away hwnd, or the titleContains fallback with titleTag off). Next step: add a debug field to the verb response echoing the exact target windowTarget returned, compare against the known-good hwnd, and fix the resolution. The verb, hints, and pup-progress sub-skill are otherwise shipped and correct; only the paint targeting is broken. Also worth checking whether the agentActivity auto-strip suffers the same defect on tiled buttons, since it shares windowTarget.

1 Reply

John Lauer · 2mo ago

Fixed in 2.0.244, pixel-verified: pup_progress {mode:"value", value:60} now paints the Win11 progress pill on the button (blue fill at 60% with the grey remainder, cropped straight off the taskbar).

Root cause was not windowTarget. It is the same one as #58: this desktop runs minimalTouch: "on", and the verb was wrapped in if (process.platform === 'win32' && !minimalTouch()). So on a minimal-touch box the verb made no shell call at all — and still answered ok:true. That is why a direct desktop_taskbar {hwnd} painted while the verb "did nothing": there was nothing to compare, because the verb never called.

Two changes:

A caller asking for a progress bar is an EXPLICIT request, not pup's automatic machinery. Minimal-touch exists to stop pup decorating windows on its own; it must not swallow a verb the caller invoked on purpose. The paint now runs regardless of the setting (same reasoning as #58's force).
The response stops lying. It now carries painted: true|false, and when nothing was drawn it says why (notPainted: "…") — non-Windows desktop, or the shell call failed with its message. ok:true no longer implies a bar appeared.

Worth noting for the class: minimalTouch silently gated several caller-visible verbs while their responses reported success. #58 (taskbar alert) was the same disease with a misleading title-related hint on top. Both are closed; if you see another "pup says ok but nothing happened" on this box, suspect this gate first — the dashboard shows a minimal-touch chip per session when it is on.

John Lauer closed this · 2mo ago