Adom Bridge (macOS)

@kyle, on Hydrogen for Mac nothing tells the AI that the Adom Bridge target is the Mac the workspace runs on. The AI treated the user's own MacBook as some other machine, said "your Mac" was offline while the user was typing on it, and then drove Chrome on "Mac.office.adom.inc" without being able to say whether that was the computer in front of the user. The user found that alarming, and rightly: the tooling cannot answer "which computer are you about to drive?"

ah 0.1.429 (build 5c34edd9-dirty) · ab on the Mac 1.9.232 · workspace relay 1.9.232 · CLI on PATH 2.1.188 · adom/hook 1.4.5 · adom/core 4.15.3 · adom/hydrogen-mac-bootstrap 0.1.30 · macOS 27.2 · 2026-11-10 UTC

What the AI sees

• adom-context: Where: a Linux container (localhost.localdomain), not the user's PC. Reach the user's machines only through adom-bridge. and Adom Bridge machines: Mac.office.adom.inc (macOS, offline).
• adom-bridge targets: one target, Mac.office.adom.inc, with "thisMachine": null and "primaryMachine": null.
• adom-bridge --target Mac.office.adom.inc status: "hostname": "Drews-MacBook-Air". The Mac's ComputerName is "Drew's MacBook Air" and its LocalHostName is Drews-MacBook-Air. The relay name Mac.office.adom.inc looks like the office network's reverse-DNS name and matches neither.
• The workspace does know it lives on a Mac: ADOM_BRIDGE_MODE=local, ADOM_HYDROGEN_MACHINE=Adom-Workspace-6a0f713bf2, and GET $ADOM_HYDROGEN_CONTROL_URL/container-status returns runtime: "macos".
• The CLAUDE.md start-here block's "Where you are" section only describes the Windows (WSL2) local workspace and the cloud container, so a Mac local workspace reads as "cloud container".

Proof it is the same machine (took about ten tool calls to establish)

Hydrogen's GET /bridges/fusion360/log and the bridge's read_file of /Users/drew/Library/Application Support/adom-hydrogen/bridge-logs/fusion360.log returned identical content (SHA-256 prefix daf91983742207b5). Nothing in targets, status or adom-context says this directly.

Ask

1. In a Hydrogen local workspace on macOS, fill thisMachine in targets with the target that hosts the workspace. Hydrogen already knows (it runs on that Mac and owns the embedded ab). The CLI could ask the control API at ADOM_HYDROGEN_CONTROL_URL, or the relay could tag the embedded ab's client as the host.
2. Name the Mac's relay client after its ComputerName / LocalHostName (or show both) rather than a network DNS name like Mac.office.adom.inc.
3. Default primary_machine to the host Mac in a local workspace, so an unqualified request goes to the user's own computer instead of "ask the user".
4. adom-context (adom/hook) and the start-here block: on a Mac local workspace, say "Hydrogen local workspace on ; target is this Mac", not "a Linux container, not the user's PC". Also, adom-context printed offline because CLI 2.1.185's targets rows had no reachable field; a missing field should read "unknown", not "offline".

Related: the companion issue on the 2.1.x CLI's false ping "unreachable" on this same workspace, adom/adom-bridge-macos#7 (relay port), adom/adom-bridge#238 and #240 (false "offline" on Windows peers).

Filed by Drew's AI agent at Drew's request.