NB (macOS) — Native Browser Bridge

Your real browser, driven by AI — on macOS. The standalone macOS build of Adom Native Browser. Your AI's hands in your own signed-in Chrome and Edge on a Mac.

This package installs the bridge's SKILLS into your container so your AI knows how to drive it; Adom Bridge loads the bridge runtime itself from the release zip (paste the manifest URL into Bridge's "+ Bridge" dialog, or adom-bridge bridge_install {manifestUrl}).

Two layers:

• nb (layer 1) — opens URLs in your real, signed-in Chrome/Edge profile on day one, with nothing installed but the browser. The OAuth/consent path: your AI opens the page, you click.
• nbe (layer 2, the Adom Native Browser Extension) — your AI fully drives that browser: navigate, click, type, read, screenshot, real logins with your own saved passwords, downloads behind auth. Loaded once via chrome://extensions → Developer mode → Load unpacked (the installing-the-extension skill walks your AI through doing it for you).

This is the macOS app (native-browser-macos), forked from the Windows line at adom/nb-bridge and stripped of all Windows code: the browser user-data root lives under ~/Library/Application Support/<browser>, Chrome is detected in /Applications, windows match by appBundleId, the native-messaging host registers as a file under ~/Library/Application Support/<browser>/NativeMessagingHosts/, and saved-password decryption uses the macOS Keychain. It is not pup — pup drives a throwaway Chrome-for-Testing with no logins; nb drives the browser you are actually signed into.

Install

• Runtime (on your Mac): paste this page's manifest URL into Adom Bridge's "+ Bridge" dialog, or adom-bridge bridge_install {manifestUrl}. Bridge streams the release zip, verifies it, and runs it.
• Skills (in your container): adom-wiki pkg install adom/nb-bridge-macos (or adom-bridge sync_skills).

Background by default on macOS (how it is enforced here)

nb promises that a driven window never lands on top of the user's work. On Windows that falls out of the OS: an unfocused new window stays behind the foreground app. macOS draws a new window of a non-active app on top of whatever the user is doing, even though it never takes keyboard focus, and there is no public API to order another app's window behind the frontmost one (System Events is denied by doctrine). So this app keeps the promise differently (adom/nb-bridge#52):

• nbrowser_open_window without a justified userRequestedForeground opens the window minimized (Dock). Extension 0.2.20 honours state:"minimized" and re-minimizes right after create. The window is fully drivable while minimized: eval, navigate, wait_for, click all work. Screenshots are the one exception: CDP cannot capture a minimized Chrome window on macOS ("Detached while handling command", measured), so nbrowser_screenshot restores the window for about a second, captures, and re-minimizes it (macRestoredForShot:true; noRestore:true opts out). The open reply carries keptBackground:true, macBackground:"minimized".
• A caller may pass its own state:"normal"|"maximized" or bounds; that is honoured, and it WILL be drawn over the user's work. Restore a minimized window only when the user asks to see it.
• After every open the bridge audits the frontmost app. If the browser got activated over the user's app, it hands focus back (desktop_bring_to_front on one of that app's windows) and records a focus_violation activity row plus a _warning in the reply.
• hwnd is null while the window is minimized: macOS lists on-screen windows only, so there is no CGWindowID to badge or label yet. Nothing that drives the page needs it.

Safari (nbe for Safari, new)

nb drives your real, signed-in Safari too. Safari has no Chrome-style native messaging and no DevTools access for extensions, so the Safari build works differently under the hood but answers the same nbrowser_* verbs, with the same safety rules (only windows the AI opened, background by default, spawn tracking, profile pinning).

Install (once per Mac):

1. Download Adom-NB-for-Safari-<version>.zip from this page's release, unzip, move Adom NB for Safari.app to Applications and open it once. It is signed with Adom's Developer ID and notarized by Apple.
2. Safari > Settings > Extensions: tick Adom.
3. Allow it on every website in each Safari profile: Edit Websites > Other websites: Allow (or click Always Allow with "Remember for other websites" ticked when Safari asks). Safari hides windows, tabs and cookies of sites Adom is not allowed on, so this step is required.

Each Safari profile shows up as its own key, safari:<profile> (nbrowser_status). Target it with profile:"safari:..." or browser:"safari".

What works, in the background (window minimized, your focus never taken):

Limits (Safari platform, not bugs):

• No trusted input: sites that require a real user gesture, anti-bot checks, CAPTCHAs and some sign-in forms may ignore simulated clicks and typing. CSS :hover cannot be triggered.
• DOM screenshots are close but approximate: web fonts can fall back, CSS icon glyphs and iframes are placeholders. Use pixelExact:true when exact pixels matter.
• No saved-password login (nbrowser_autologin refuses): Safari's Passwords app is not readable by any other app. Drive sites you are already signed into.
• No recording from the extension, and downloads a page starts itself cannot be watched.
• Each Safari profile asks for website access separately.

Built from the Chrome extension's own code (copied verbatim, three mechanical substitutions) plus a shim (safari/overlay/src/safari-shim.js); sh scripts/build-safari.sh --app rebuilds it, safari/test/battery.mjs and safari/test/explore.mjs are the live tests (23/23 and 24/24 on 2026-10-21, Safari 26.6.2).

Verbs

88 nbrowser_* verbs (nbrowser_describe '{}' for the full catalog). Read nbrowser_readiness first: state:"needs-extension" means offer to load the extension (never make the user do it themselves).