1Password extension on second instance of Chrome working weird

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.

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.

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...?

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

Chrome:default:

Chrome:custom:

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

Don't they test their software?

@Joy_1P In case of not being notified...

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.

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.

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.