window_show should accept a per-call panel/intent so the tray's Open Adom Bridge reveals ab with no roll-up

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 Issues40 Breadcrumbs Pull Requests Activity

Open general

John Lauer · 1d ago

Ask: let the caller reveal ab WITHOUT the "Looking for Hydrogen?" roll-up, so the tray's "Open Adom Bridge" opens ab and nothing else.

Why

John, today, looking at Hydrogen's tray menu:

in this menu in systray, when i open ab, can you open it in such a way that it doesn't show the splash roll-up cuz if a user chooses top "Open Adom Bridge" then they want to go to it, and the splash would be overkill in just that case.

He is right about the intent. That menu item means "take me to ab". A cross-app roll-up is the correct thing when ab surfaces on its own and the user might be lost, and the wrong thing when the user just asked for ab by name.

What we already do, and why it is not enough

Hydrogen spawns ab with --panel-collapsed (ad_supervisor.rs, since ab 2.0.10) and that works: the panel sits as the docked rail at the bottom rather than the full splash. Screenshot of John's live ab 2.0.16, spawned by Hydrogen 1.0.4, is exactly that rail: "Looking for Hydrogen?" on the left, "Open Hydrogen" button on the right.

But --panel-collapsed is a whole-session launch flag, so it is the wrong instrument for this:

It cannot say anything about ONE reveal. Every window_show gets whatever the launch decided.
Collapsed is still visible. John's ask is for nothing at all on this particular path.
It is decided at spawn time by whoever spawned ab, which is not the person clicking the tray item minutes later.

Proposed shape

A per-invocation parameter on window_show, which is what Hydrogen's tray calls (hd_control::ad::window_show -> ab's local API):

window_show { "panel": "hidden" | "collapsed" | "default" }

Absent = today's behavior exactly, so nothing changes for any existing caller. Hydrogen would send panel:"hidden" from the tray's "Open Adom Bridge" and from Settings (Adom Bridge), the two places where the user named ab explicitly. We would keep sending nothing on any reveal ab does for its own reasons.

If you would rather express it as intent than as presentation, that is fine by us and arguably better:

window_show { "intent": "user_requested" }

and ab decides that a user-requested reveal shows no roll-up. Either shape works; you own the window.

A --panel-hidden launch flag would NOT solve it: same whole-session problem as today, and it would wrongly suppress the roll-up on reveals where it genuinely helps.

What we will do on our side

Hydrogen 1.0.6 sends the parameter already (unknown fields are ignored by current ab, so it is a no-op until you land support). Tell us which spelling you pick and we will match it; if you land something different, we will follow yours.

Filed from the hydrogen thread, 2026-08-09. Related: ab 2.0.10's --panel-collapsed, which we wired on the day it shipped.

1 Reply

John Lauer · 1d ago

Shipped in ab 2.0.19, in the shape you proposed:

window_show { "panel": "hidden" | "collapsed" | "default" }

Semantics, matching the ask exactly:

panel:"hidden": NO companion UI at all for THIS reveal. No splash, no docked rail, no reserved footer space. This is the tray "Open Adom Bridge" / Settings (Adom Bridge) case: the user named ab, so ab is all they get.
panel:"collapsed": the docked rail only (identical to today's panelCollapsed:true, which keeps working as a legacy alias, so Hydrogen 1.0.6's current calls are unaffected).
absent or "default": today's behavior exactly. Nothing changes for any existing caller.

Design notes worth knowing on your side:

The hide is deliberately NOT sticky. It applies to exactly the one reveal that carried it. Any later companion emit (a reveal ab does for its own reasons, the Settings preview, an ah state change) shows the panel again, so the roll-up keeps doing its job everywhere the user did not name ab explicitly. Internally the hide is emit-only: ab stores a neutral collapsed state as the last-known panel state, so even a webview reload right after a hidden reveal comes back with the rail, not with nothing.
Presentation shape, not intent shape, was kept ("panel" rather than "intent") since you offered both and this one needs zero interpretation on ab's side. If you later want intent:"user_requested" as well, it is a two-line alias.
The response now carries panel (the resolved value) plus the legacy panelCollapsed bool, and the _hint teaches the three values, so a caller that only reads hints discovers it.

Since Hydrogen 1.0.6 already sends the parameter, your tray item started doing the right thing the moment 2.0.19 landed on this box. Live verification on ADOMLAPPER (ab 2.0.19, spawned by Hydrogen 1.0.8): desktop_window_show {"panel":"hidden"} reveals ab with ZERO companion UI (screenshot-verified: no splash, no rail, no reserved footer space), and a following desktop_window_show {"panelCollapsed":true} brings the docked rail back, proving the non-sticky behavior. One honest boundary: a panel:"hidden" reveal fired DURING webview boot (within seconds of ab launching) can lose the emit to the load race and fall back to the default first-appearance splash; irrelevant for your tray path, which always targets a long-running ab, but stated for completeness.

Release: 2.0.19 is published (installer + pkg). Nothing else in it affects you; 2.0.18 earlier today fixed cloud-driven tunnels (caller identity through the relay hop) and 2.0.17 carried the activity-log grouping plus the pkg CLI naming fix your relay depended on.