app

Adom Bridge

Public Made by Adom

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

adom-bridgetauriclaude-codebridgekicadfusion360puppeteerdesktop-automation
Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity
Open bug report

desktop_decrypt_browser_credentials: Chrome 156 app-bound key unwrap fails ('unknown ABE flag 0x9a'), no Chrome cookies or passwords decrypted

John Lauer · 13d ago

Summary

desktop_decrypt_browser_credentials can't unwrap Chrome's app-bound encryption key on Chrome 156, so it decrypts no Chrome cookies or passwords at all. Its stats carry errors: ["app-bound key unwrap: unknown ABE flag 0x9a"]. That breaks two pup imports for every Chrome user:

  • pup_import_browser_logins (passwords)
  • the new site-session import (pup_import_browser_logins {sessionFor}, cookies)

Environment (AdomLapper, 2026-10-28)

  • Adom Bridge 2.1.184
  • Google Chrome 156.0.8078.48, with five profiles
  • Microsoft Edge 156.0.4314.50
  • caller: pup 2.0.736 (a local bridge), include: ["cookies"], browsers ["chrome","edge"]

What came back

  • stats: {"cookies_decrypted": 51, "cookies_failed": 0, "profiles_scanned": 6, "errors": ["app-bound key unwrap: unknown ABE flag 0x9a"]}
  • 51 cookies came back in all, none of them for x.com. The user is signed in to x.com in Chrome (Profile 1), so the Chrome cookie store wasn't decrypted at all. The 51 appear to be Edge's.
  • cookies_failed: 0 hides this: the Chrome rows were never attempted. A failed key unwrap should count each skipped profile, or return an error code such as abe_unsupported, so callers can tell the user why.

Likely cause

Chrome's app-bound encryption added a new key-blob flag (0x9a). The helper knows only the earlier flags, so it gives up on the Chrome key and skips Chrome entirely.

Ask

  1. Support the new ABE key-blob format (flag 0x9a) in the signed decrypt helper.
  2. When a browser's key can't be unwrapped, report it per browser (an error code, plus the profiles skipped), not as cookies_failed: 0.

Found while signing John into x.com in pup through the session import (adom/pup-bridge#136).

1 Reply

John Lauer · 13d ago

Re-scoping this: retire the helper, don't re-adapt it

After thinking it through with John, the fix we want is not "support the new ABE flag 0x9a." That path just broke on Chrome 156, and it will break again on the next hardening bump, because unsealing Chrome's store from outside Chrome is a standing arms race against Chrome's own security model. It is also the one primitive in ab that is shaped like credential-exfil tooling, which trips safety classifiers on exactly the consented, own-machine use we built it for.

So the proposal is to move the capability onto paths where Chrome does its own decryption with the user present, and retire desktop_decrypt_browser_credentials rather than keep it on life support.

The replacement lives across the two bridges that already own the right surfaces:

  • nb-bridge#54 (session case): read one site's live session from the user's real signed-in browser and hand it to pup. Fixes the x.com case (adom/pup-bridge#136) with no store-cracking, since the user is already logged in there.
  • nb-bridge#55 (bulk import): drive Chrome's own consented password export (Windows Hello) and hand pup the result to import.
  • pup-bridge stays the vault, matcher and autofill, unchanged.

That leaves ab holding nothing credential-shaped.

Ask (revised)

  1. Keep the per-browser error reporting fix from the original ask (point 2): a key that can't be unwrapped should report per browser with the profiles skipped, not cookies_failed: 0. That is worth having regardless, so callers can explain the failure.
  2. Plan to deprecate and remove desktop_decrypt_browser_credentials once nb-bridge#54 and #55 land and pup has cut over. Until then, have it return a clear abe_unsupported code so pup routes users to the nb paths instead of failing silently.

Leaving the original title and body for the record; the decrypt bug is real, we're just choosing not to chase it.

Log in to reply.