CLI on Sequoia via ssh - settings.json: operation not permitted

Michael Mercurio

Since upgrading macOS to Sequoia, when executing op via a logged in ssh session, op fails to access my 1password settings:

10:45PM | DEBUG | Skipped loading desktop app settings file. The desktop app might not be installed: read file: open /Users/USER/Library/Group Containers/2BUA8C4S2C.com.1password/Library/Application Support/1Password/Data/settings/settings.json: operation not permitted

Previously on macOS Sonoma 14.7.4 executing op while logged in over ssh works as expected:

op --version 
2.30.3

op account list
URL                 EMAIL                    USER ID
my.1password.com    email@exmaple.com    USERIDXXXX

ssh localhost 
Last login: Mon Nov 25 22:21:11 2024 from ::1

op account list
URL                 EMAIL                    USER ID
my.1password.com    email@exmaple.com    USERIDXXXX

Now on macOS Sequoia 15.1.1:

op --version 
2.30.3

op account list
URL                 EMAIL                    USER ID
my.1password.com    email@exmaple.com    USERIDXXXX

ssh localhost
Last login: Mon Nov 25 22:30:32 2024

op account list

op account list --debug
10:45PM | DEBUG | Skipped loading desktop app settings file. The desktop app might not be installed: read file: open /Users/USER/Library/Group Containers/2BUA8C4S2C.com.1password/Library/Application Support/1Password/Data/settings/settings.json: operation not permitted

Any ideas what's going on? Could this be related to permissions changes in Sequoia?

This breaks all kinds of workflows I use daily and is a major problem since I routinely execute op over ssh back to my desktop while logged into remote systems for development and troubleshooting.

Appreciate any insights or suggestions.

Cheers,
Michael

---

1Password Version: 8.10.52
Extension Version: Not Provided
OS Version: 15.1.1
Browser: Not Provided

Michael Mercurio

This appears to be some security feature of Sequoia and not directly related to 1Password. I'm unable to access the files under ~/Library/Group\ Containers/2BUA8C4S2C.com.1password/ when logged in via ssh. 😞

Example:

head -2 ~/Library/Group\ Containers/2BUA8C4S2C.com.1password/Library/Application\ Support/1Password/Data/settings/settings.json
{
  "version": 1,

❯ ssh localhost
Last login: Mon Nov 25 23:02:46 2024 from ::1

❯ head -2 ~/Library/Group\ Containers/2BUA8C4S2C.com.1password/Library/Application\ Support/1Password/Data/settings/settings.json

head: /Users/USER/Library/Group Containers/2BUA8C4S2C.com.1password/Library/Application Support/1Password/Data/settings/settings.json: Operation not permitted

Ugh. Anyone have a way to work around this?

Michael Mercurio

Solved. Apparently "Allow full disk access for remote users" somehow became unchecked. Once setting this under System Settings > General > Sharing > Remote Login, everything is back to working again.

😊

mattphylum

I'm having a related problem with local terminals. I have op completion zsh in my profile, so every time I launch a terminal I get a "whatever.app would like to access data from other apps" message, and I assume the same would happen if I removed the op completion zsh line and then tried to use some other op command.

This can be worked around by granting full disk access to every terminal app (iTerm, Terminal, Visual Studio Code, etc), but it would be great not to need to disable the group container file sandbox.

Michael Mercurio

This can be worked around by granting full disk access to every terminal app (iTerm, Terminal, Visual Studio Code, etc)

I'm not sure there's a way around this. It's been like this for me (even without op completion zsh) with both iTerm2 and Terminal for a few macOS versions now. Full Disk Access will likely be needed depending on which directories need to be accessed.

I wish there was a way to make the access controls more flexible (e.g, grant specific applications access to specific directories.) Kind of off topic, but if you find a way to make this work better, please post an update.