Why can’t sandboxed mac app store apps have full disk access available in the system settings for full disk access?
I discovered mac app store apps in release mode cannot access the ai auggie command line program and other command line programs like opengrep on your system. Debug builds fine.
I came up with a workaround: Since I have an ssh client built in for connecting to remote servers, why not connect to ssh on the same local machine… Ask the user for their username and password in a popup.
To do this, you have to enable remote login on your mac in system settings -> sharing.
In addition you must grant full disk access to cli ssh in system settings: add /usr/libexec/sshd-keygen-wrapper
It all works, but I don’t see the cli program in mac settings. To remove the cli program you must run a command line program to remove all full disk access support from all apps. No way to just undo ssh.
So my question is, even though I got CodeFrog all working for a mac app store release, should I not do it because it’s insecure or too complicated with the system settings? Should I instead sell the app off the store like Panic Nova?
Need some advice. I have not implemented in app purchases yet. Should I just have a reality check and sell the app off the store, or try for app store approval?
Bummer…
Maybe I’m ahead of my time, but perhaps Apple could review the source code for apps requesting full disk access and make sure there’s nothing fraudulent in them. Then, developer tools app store apps could be in the store with the user’s assurance that nothing is happening behind the scenes that is scary.
From: https://blog.greenrobot.com/2025/11/10/i-have-a-decision-to-make/
Related post: https://developer.apple.com/forums/thread/806187
I submitted a code level tech support question for this. They directed me here.
You’re conflating a bunch of different things here.
I discovered mac app store apps in release mode cannot access … other command line programs
First up, terminology. When we talk about Debug and Release mode, those are build configurations. That’s technically independent from Development and Distribution code signing. While it’s common for folks to combine the Debug build configuration with Development signing, that’s not required. In fact, sometimes it’s useful to mix these up. I explain one such case in Isolating Code Signing Problems from Build Problems.
None of that’s related your actual issue though. Rather, App Store apps must enable the App Sandbox, and that limits the app’s ability to access the file system. And specifically, when it comes to executables:
- If a sandboxed app spawns a child process, that process inherits the app’s static sandbox. Many command-line tools don’t work when sandboxed.
- A sandboxed app can only run executables that are available to its static sandbox. While you can dynamically extend the sandbox to support file read and write, that doesn’t work for the executable privilege. And given that most third-party tools are not within the app’s static sandbox, that’s often a showstopper.
I talk about both of these in some detail in On File System Permissions.
AFAIK there’s nothing stopping you granting Full Disk Access to a sandboxed app, but that doesn’t bypass the App Sandbox checks. The app will only be able to access items within its static or dynamic sandbox.
I don’t see the cli program in mac settings.
This in on macOS 26.1, right?
If so, that’s Just A Bug™ IMO, something that I’ve called out in the thread you referenced.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
