[Bug]: 1Password demands the account password on every unlock in ego lite (bundle ID not on 1Password's supported-browser list)

[solarhell]

Affected component

ego lite browser app

What happened?

With the 1Password extension (aeblfdkhhhdcdjpifhhbdiojplfjncoa, v8.12.32.33) installed in ego lite, 1Password never grants the extended / biometric unlock session. It demands the full account password on every single unlock, with this reason:

You're being asked for your password again because Chrome has an available update.
（你被要求再次输入密码，因为 Chrome 有可用更新。）

ego lite is already up to date — chrome://settings/help says "ego 已是最新版本 / 版本 0.4.6.13（正式版）lite (arm64)". There is no update to apply and the message never goes away. The same 1Password account in Google Chrome on the same machine unlocks with Touch ID normally.

The message is a red herring. The actual cause looks like this: ego lite tells the extension it is Chrome, but tells the OS it is Citro Labs, and 1Password's native helper only trusts a fixed list of browser bundle IDs.

1. ego lite's user agent reports Chrome/150.0.7871.101, so the extension identifies the browser as Chrome:

   $ strings "/Applications/ego lite.app/Contents/Frameworks/ego Framework.framework/Versions/Current/ego Framework" | grep -E '^Chrome/[0-9.]+$'
   Chrome/150.0.7871.101
   

2. 1Password's native messaging helper then verifies the real binary behind that claim, and logs it:

   $ tail ~/Library/Group\ Containers/2BUA8C4S2C.com.1password/Library/Application\ Support/1Password/Data/logs/BrowserSupport/1Password_rCURRENT.log
   INFO [1P:native-messaging/op-browser-support/src/main.rs:469] Starting 1Password-BrowserSupport 8.12.30 production build no. 81230021.
   INFO [1P:native-messaging/op-browser-support/src/browser_verification/apple.rs:20] Verifying browser "/Applications/ego lite.app/Contents/MacOS/ego lite"
   INFO [1P:native-messaging/op-browser-support/src/main.rs:177] waiting for potential partner browser authorization from B5X
   

   That last line is the "unsupported / partner browser" path, and it is the only outcome this helper ever reaches here — it repeats identically in all 1000+ rotated BrowserSupport logs on this machine.

3. The helper binary carries a hardcoded allowlist of browser bundle IDs, and com.citrolabs.ego.lite is not on it:

   $ strings "/Applications/1Password.app/Contents/Library/LoginItems/1Password Browser Helper.app/Contents/MacOS/1Password-BrowserSupport" \
     | grep -oE 'com\.(google|brave|microsoft|vivaldi|apple)[A-Za-z.]*' | sort -u
   com.apple.Safari
   com.brave.Browser          (+ .beta / .development / .nightly / .origin*)
   com.google.Chrome          (+ .beta / .canary / .dev)
   com.microsoft.edgemac      (+ .Beta / .Canary / .Dev)
   com.vivaldi.Vivaldi        (+ .snapshot)
   

   Its verification result enum is CodeSignatureError | InvalidBrowserSignature | UnsupportedBrowser | NotSigned | MissingRequirementInfo, alongside a CodeSignatureHasMatchingTeamId check. ego lite is signed by a different team, so it cannot match the identity the extension claims:

   Identifier=com.citrolabs.ego.lite
   Authority=Developer ID Application: CITRO LABS PTE. LIMITED (JGQLC6YQYJ)
   

So 1Password sees a browser claiming to be Chrome whose signature is not Chrome's, refuses to establish a trusted browser session, and surfaces the closest canned explanation it has — a pending Chrome update. Possibly reinforced by a plain version comparison: ego lite claims Chrome/150.0.7871.101 while current stable Chrome on this machine is 151.0.7922.109, which on its own reads as "Chrome has an available update".

This matters beyond one extension: ego lite's whole premise is reusing the user's logged-in browser state, and a password manager that demands the full account password on every unlock is exactly the friction people adopt 1Password to avoid.

Steps to reproduce

1. Install ego lite 0.4.6.13 on macOS with the 1Password 8 desktop app
   and Touch ID / system unlock enabled.
2. Install the 1Password extension (aeblfdkhhhdcdjpifhhbdiojplfjncoa) in ego lite.
3. Open chrome://settings/help and confirm ego reports it is up to date.
4. Lock 1Password, then click the extension icon to unlock.
5. Observe: no Touch ID prompt. The account password is required, with the note
   "You're being asked for your password again because Chrome has an available
   update." This repeats on every unlock, indefinitely.

# Confirm which path 1Password took:
tail ~/Library/Group\ Containers/2BUA8C4S2C.com.1password/Library/Application\ Support/1Password/Data/logs/BrowserSupport/1Password_rCURRENT.log
# -> Verifying browser "/Applications/ego lite.app/Contents/MacOS/ego lite"
# -> waiting for potential partner browser authorization from B5X

Expected behavior

1Password should be able to verify ego lite as a legitimate browser and keep its extended / biometric unlock session, the same way it does in Chrome, Brave, Edge and Vivaldi — instead of falling back to an account-password unlock every time with a message that points at a non-existent Chrome update.

Version

ego lite 0.4.6.13 (official, arm64); 1Password extension 8.12.32.33; 1Password-BrowserSupport 8.12.30 (build 81230021)

Environment

macOS 26.5.2 (25F84), Apple Silicon (arm64), 1Password 8 desktop app integration

Logs or screenshots

BrowserSupport log (identical in every rotated file):
  Verifying browser "/Applications/ego lite.app/Contents/MacOS/ego lite"
  waiting for potential partner browser authorization from B5X

ego lite code signature:
  Identifier=com.citrolabs.ego.lite
  Authority=Developer ID Application: CITRO LABS PTE. LIMITED (JGQLC6YQYJ)
  flags=0x12a00(kill,restrict,library-validation,runtime)
  Notarization Ticket=stapled

ego lite UA brand token:      Chrome/150.0.7871.101
Google Chrome on same machine: 151.0.7922.109

Additional context

• Frequency: every unlock, 100% reproducible, persists across browser and machine restarts.
• The same extension in Google Chrome (v8.12.30.21) on this machine unlocks with Touch ID without complaint.
• Possible directions, in rough order of how well they'd actually fix it:
  1. Get com.citrolabs.ego.lite onto 1Password's supported-browser list. The log line literally mentions partner browser authorization, and Brave / Vivaldi are on that list — there appears to be an established path for Chromium forks.
  2. If a browser-side handshake exists for the partner-authorization flow, implement it so the extension can be authorized once instead of never.
  3. Short term, keep the UA's Chrome token in step with current Chrome stable, in case the specific "available update" wording is driven by a version comparison rather than the signature check.
  4. At minimum, document the limitation so users don't assume their ego lite install is broken.
• Unrelated minor finding, noticed while investigating: EgoUpdater does not prune superseded framework versions. Contents/Frameworks/ego Framework.framework/Versions/ still holds 0.4.6.12 (Aug 7) beside 0.4.6.13 (Aug 12), whereas Chrome's bundle keeps only the current version. Not the cause of this bug, but probably worth a separate look.

Before submitting

• I searched the existing issues and did not find a duplicate.
• I removed secrets and sensitive browsing data from this report.

[liuwd8]

Thank you for your feedback. We are awaiting Apple's approval of our access to Touch ID key management. We will release an update as soon as approval is granted.

We will be updating our Chrome version soon; updating Chrome is usually very quick for us. However, due to some scheduling issues, the update may cause problems with an upcoming important update. Therefore, we have postponed it until after the important update is released.

Thank you again for your patience.