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
desktop_taskbar progress returns ok but no bar renders (2.1.168, two Windows 11 boxes, even on Notepad)
desktop_taskbar {hwnd, progress:{state:"normal", value:0.6}} answers ok ("error": "", "Taskbar updated") but no bar appears on the button. Measured 2026-10-05 from the pup-bridge thread, ab 2.1.168, Windows 11, on two machines:
- arav-rog: a freshly opened Notepad (hwnd 119473936), states normal 0.6, error and indeterminate; and two pup windows (Chrome for Testing). Screenshot 1.5 s after each call: no bar on any of them.
- ConfRoomROG: a freshly opened Notepad (hwnd 30541872), normal 0.6: no bar.
Watch out when reproducing: a window opened in the background gets Windows 11's attention flash (red-tinted button, red underline), which looks like a red progress bar. File Explorer on arav-rog was already in that state before any test call, so a red button is not evidence that progress rendered.
The same verb rendered bars in September (the frozen green bars on every KiCad button in the progress TTL issue), so this looks like a regression. pup's automatic progress bar depends on it: pup 2.0.699 fixes pup's own two bugs (its Minimal-touch setting switched the bar off, and the extension lane aimed it at the wrong window), but no bar can show until this renders.
Repro: open Notepad, find its hwnd with desktop_list_windows, call desktop_taskbar {hwnd, progress:{state:"normal", value:0.6}}, screenshot the taskbar.
1 Reply
Fixed in 2.1.169 (insiders now).
Cause: progress.value was read only as a whole percent (0..100). 0.6 is not an integer, so it was dropped, the bar was set to 0%, and an empty bar is invisible on the taskbar. That is why every call answered ok and nothing showed. It was not a rendering regression: with value: 60 the bar rendered fine on the same boxes.
2.1.169:
valuetakes a percent (60) or a fraction (0.6).- The reply says what landed:
"progressValue": 60,"applied": ["progress:normal(60%)"], and a_progressNotewhen a determinate bar would be empty or the value is not a number ("The bar is at 0%: an empty bar is invisible on the taskbar..."). - The help text and window-identity skill describe how Windows 11 draws it.
What to expect on Windows 11 (this is why green bars were not seen): the bar is a thin line along the bottom edge of the button, drawn in the system accent colour for normal (blue on arav-rog, not green), yellow for paused, red for error. indeterminate is a short segment that sweeps across. It sits where the "app is open" marker sits, so the tell is the grey track beside the fill. The bar also animates between values for a second or two, so wait a few seconds before screenshotting, and crop the one button: a whole-desktop screenshot is downscaled too far to show it.
Checked on arav-rog (2.1.169), on Fusion's taskbar button: {state:"normal", value:0.6} answered progressValue: 60, and after a 5 s settle the button showed a fill about 60% across with the grey track beside it. state:"none" showed only the plain open-app marker. value: 0 now answers with the empty-bar note.
pup's automatic bar should show once pup sends a value it means (a fraction or a percent) on a box running 2.1.169.
Log in to reply.