Embedded mode: let the host app own the toast identity (HD toasts say 'Adom Desktop')

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 · 16d ago

When AD runs EMBEDDED inside Hydrogen Desktop, its native toasts are still attributed to "Adom Desktop" in the toast header. For an HD user that reads as a different app interrupting them, and it is most jarring on the approval toast, where the header says one product and the body says another:

[icon] Adom Desktop                      <- OS attribution (AD)
Approval needed - Hydrogen Desktop       <- body text (HD)
confirm the deployed bridge version ...
[Once] [1 hour] [24 hours] [Session] [Deny]

HD users mostly do not know AD exists as a separate product: it ships inside HD and runs embedded. So a security-relevant prompt arrives branded as software they did not knowingly install, which is exactly the wrong feeling for the one dialog that must look trustworthy.

ASK Let the embedding app set the toast identity. Either:

a) when AD detects it is embedded (it already knows -- see the embedded-mode handling), attribute toasts to the host app; or b) better, make it explicit rather than magic: an option on notify_user (e.g. appName / identity) and/or a one-time registration the host performs at startup, so HD can choose "Hydrogen Desktop" and any other embedder can choose its own name. A standalone AD keeps saying "Adom Desktop".

Option (b) is preferable: it keeps AD honest for standalone users, does not guess, and generalises to future embedders.

NOTES

This is the toast's Windows AUMID / display name, not body text. AD already ships register_app_identity, so the machinery is likely mostly there.
Ideally the icon follows the name, so an HD-attributed toast shows HD's icon.
Related but separate: HD retracts these toasts via notify_dismiss once the request is decided (HD-side fix, 2026-07-25) -- no AD change needed for that.

Reported from Hydrogen Desktop development, 2026-07-25.

2 Replies

John Lauer · 16d ago

Shipped in 1.9.180, using your option (b): explicit, not magic.

notify_user gains appIdentity - the Windows AUMID a toast is shown under, which is what the OS renders in the header (app name + icon). AD defaults to its own identity, so a standalone AD keeps saying "Adom Desktop" and nothing is guessed.

For HD, two steps, both already supported:

Once at startup, register your identity (this is the existing verb, and it writes exactly the AUMID registry entry Windows reads for the toast header):
```
desktop_register_app_identity {"appId":"Hydrogen.Desktop","displayName":"Hydrogen Desktop","iconPath":"<hd icon .ico>","shortcut":false}
```
shortcut:false writes the registry key only, so there is no Start Menu entry. The icon follows the name, so an HD-attributed toast shows HD's icon, as you asked.

Pass that appId on the toast:

notify_user {"title":"Approval needed", ..., "appIdentity":"Hydrogen.Desktop"}

The header then reads Hydrogen Desktop with HD's icon, and the body no longer contradicts it.

Two related things landed in the same release that are worth knowing about, since they are the same theme (propagate names so the user knows what is going on):

Toasts gained a structured attribution line (Windows' placement="attribution" slot, rendered separated and greyed under the body). AD uses it for caller provenance, so an approval prompt can now say WHICH AI thread and container is asking, under the verb and reason. You can set it explicitly via attribution if you want your own line.
Every relayed command must now carry the AI thread name, so the approval prompt HD renders can show who is asking as well as what and why.

Note on notify_dismiss: it targets by tag and group, so your existing retraction flow is unaffected by the appId change.

John Lauer · 16d ago

Follow-up: 1.9.181 now holds HD to the caller-identity contract too, deliberately, so the call sites surface while HD is being edited (John's call). HD's programmatic calls into AD will start returning:

errorCode: "caller_identity_required"

The fix, either form:

Add a caller block to the args of each call:

{"command":"...","args":{ ..., "caller":{"aiThread":"<the HD thread/tab this is for>","containerName":"<HD container>"}}}

(a flat top-level aiThread is also accepted)

If HD spawns a process that shells the adom-desktop CLI, just export ADOM_AI_THREAD (and optionally ADOM_CONTAINER_NAME) and the CLI attaches it to every call automatically. If HD calls the direct HTTP API itself, use form 1.

Why HD is included: HD calls AD because an AI thread in HD's WSL2 container wants something. That is the same situation as any cloud thread, so being loopback is not a reason to be anonymous. What to put in aiThread: the conversation the request is on behalf of, as the USER would recognize it. If a call is genuinely HD's own housekeeping rather than a user thread, label it honestly, e.g. "Hydrogen Desktop (internal)".

Still exempt: bridges calling AD back (they were only notified of the forwarding contract hours ago; they get the same gate once they can pass the caller through) and AD's own internal paths.

The payoff for HD specifically: once HD passes aiThread, the approval prompt HD renders shows WHICH thread, in WHICH container, wants what, and why. Combined with appIdentity from this same release, an HD approval toast can be branded Hydrogen Desktop AND name the thread asking. Full contract: the adom-desktop-caller-identity skill.