1Password extension on second instance of Chrome working weird

jinux_go

I have two Chrome instances running. One is launched normally (from Spotlight) and another one is launched with the different User Data Directory parameter (--user-data-dir). (This is for separating two Chrome profiles completely. Having two profiles in one instance has some limitation I don't like)

The problem is: the 1Password extension on the second instance requires a full password to be unlocked where the one on the first instance asks me the fingerprint. I guess that the 1Password desktop cannot establish two connections to a single "application" and two instances of an application anyway belong to the same application.

1. Is this an intended behavior?
2. Can Chrome Beta (https://www.google.com/chrome/beta/) satisfy my requirement? (or does 1Password establish a new connection to the Chrome Beta?)

---

1Password Version: 8.10.4
Extension Version: 2.10.0
OS Version: macos 13.3
Browser:_ Chrome

Joy_1P

Hey @jinux_go, to unlock the extension with Touch ID, the app integration feature has to be working. For the app integration feature to work, both the 1Password app and your browser have to be installed in the /Applications folder. If either the 1Password app or your browser are installed outside of the /Applications folder, our communication protocols won't be able to properly verify the browser's code signature. You'd still be able to use the app and extension, but they will not communicate or connect.

It sounds like one instance of Chrome is installed in /Applications, and Touch ID can be used to unlock the extension from there. That said, it also sounds like the second instance of Chrome is installed in a separate directory, and Touch ID does not work to unlock the extension from there. If that is truly the case, then this would be expected behavior.

I would recommend moving the second instance of Chrome into the /Applications folder if you can. Alternatively, if you do not want to use a separate profile in Chrome, you can use another browser with 1Password. You will be able to unlock the extension in that browser with Touch ID as long as that browser is installed in the /Applications folder.

I hope this helps. If I've misunderstood the situation, please let me know.

jinux_go

Thank you for your responding.
Unfortunately, the second instance of Chrome is launched from the original /Applications/Google Chrome.app. More accurately, the command line I used to launch the second instance is this: open -na 'Google Chrome' --args --user-data-dir="$separateDataDir", where separateDataDir is not ~/Library/Application Support/Google/Chrome.

jinux_go

To avoid ambiguity, let's call the Chrome execution with unmodified --user-data-dir, Chrome:default and the one with modified --user-data-dir, Chrome:custom.

I have experimented various scenarios. TL;DR: Chrome:custom never has a chance to establish the connection to the desktop app.

Scenario 1 (this is my typical setup): Launch Chrome:default from Spotlight and then launch Chrome:custom from open command
=> Chrome:default connects. Chome:custom doesn't.

Scenario 2: Launch Chrome:default from open command and then launch Chrome:custom from open command
=> Same. It seems it is nothing to do with the open command.

Scenario 3: Launch Chrome:custom from open command.
=> No connection

I assume the non-default --user-data-dir is the culprit...?

jinux_go

Another clue: right-click context menus of the extension from both executions show different items!

Chrome:default:

Chrome:custom:

jinux_go

DevTools console of Chrome:custom's 1Password extension prints:

Unknown

This content has been removed.

jinux_go

@Joy_1P In case of not being notified...

jinux_go

The difference in menu items had nothing to do with the original issue. "Lock" and "Save login" appears only when the 1Password extension is unlocked.

jinux_go

Luckily enough, I have fixed it 😀. The culprit was the native messaging manifest file. 1Password desktop (it seems) installs the manifest file at the predefined path: ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.1password.1password.json, which is under the default --user-data-dir. Since the second instance's --user-data-dir is non-default, there is no one to install the manifest there. The absence of the manifest is the direct reason for the extension being unable to connect to the desktop app.

So, I manually copy-pasted the manifest to the proper location.
The issue isn't a bug at all in the first place. My non-trivial and custom configuration is the thing.

steph.giles

Hey @jinux_go,

I am so sorry for the delay in our reply.

Thank you for the detailed update, I'm glad you were able to get things back on track.

Let us know if there is anything else we can help with at all.