File system sandboxed by Console App

Wrote a simple Console app. When first Run, a dialog popped up asking me if the app could Access The File System. I did not intend to read in any files for this app, so declined. Disaster. My console app aborted and subsequently the Terminal will not let me view any directories in my user account … “operation not permitted”.

I tried rebuilding the app in a fresh project. I also tried to delete the AppName.debug folder. No success. I tried rebooting the Terminal, and finally my entire computer. No success.

I cannot list ( “ls”) or change directories (“cd”) for any folders in the Terminal…“operation not permitted” (see below). I checked my permissions and all are still Read/Write for the folders I tried to access. Curiously, when using the Terminal in VS Code, I have full access to my directories.

Something bad happened when I declined the Allow File Access dialog on the first Run of my console app, and I cannot figure out how to repair this.

Here is the Terminal dump (with ‘AppName’ substituted for the actual name and ‘userName’ for my user account). Notice the “file system sandboxed” line, which I do not know if this is a consequence of my declining the initial dialog or not…

Last login: Fri Jan 29 08:23:16 on ttys000
userName@ userName-MacBook-Pro ~ % /Users/userName/Documents/Xojo/AppName/consoleapp/AppName.debug/AppName.debug
dyld: Library not loaded: @rpath/rbframework.dylib
Referenced from: /Users/userName/Documents/Xojo/AppName/consoleapp/AppName.debug/AppName.debug
Reason: no suitable image found. Did find:
file system sandbox blocked open() of ‘/Users/userName/Documents/Xojo/AppName/consoleapp/AppName.debug/AppName.debug Libs/rbframework.dylib’
/Users/userName/Documents/Xojo/AppName/consoleapp/AppName.debug/AppName.debug Libs/rbframework.dylib: stat() failed with errno=1
zsh: abort
userName@userName-MacBook-Pro ~ %

Here is what is happening when accessing any folder in my User account via the Terminal:

userName@userName-MacBook-Pro ~ % cd Documents
userName@userName-MacBook-Pro Documents % ls
ls: .: Operation not permitted

That sounds even more unpleasant than what happened when I tried to make some screenshots for accessing automation permission. I lost access to my keyboard because it wasn’t trusted anymore. Thanks the gods I got it back after rebooting.

Have you tried to delete the security database:

sudo killall -9 tccd
sudo rm -R /Library/Application\ Support/

Reboot immediately afterwards.

Thanks, but no luck. Did as above and rebooted. Still sandboxed for my console app (but not other console apps) and “Operation not permitted” when trying to sudo rm -R /Library/Application\ I even tried to use the Finder to delete this folder, and cannot set permissions to allow this.

I did succeed in gaining Terminal access to my Desktop and other folders, but not my Documents folder.

Somehow the sandboxing is tied to the app name or folder as I can still run other Console apps.

To do most things, you need to allow Terminal “Full Disk Access”

To do so after declining initially, you can add Terminal to the list via System Preferences:


Just ran an experiment. I ported the same code to a new Console project (with the exact same AppName and bundle identifier) , this time in a new source folder (a subfolder of Desktop). Launched perfectly and ‘Allow Access to File System dialog’ did not appear.

This made me think the problem is a permissions/file access issue in the folder where the original project was located (a subfolder of Documents). So… I drag/dropped the original project folder onto my Desktop, essentially relocating under a new Parent directory.

Launched perfectly and ‘Allow Access to File System’ dialog did not appear.

I still do not have Terminal access to my Documents folder, but I do have access to all the other root folders in my User account, including my Desktop folder. Thus, the problem may stem from Permissions/Access just to the Documents folder, and the Xojo dialog was an appropriate response at launch. When I examine Permissions (Get Info) both Documents and Desktop are the same (Read/Write) for my user account.

Still investigating but any help appreciated…


Yep. That’s it !!. I moved the original project back to its original location, and set the Security/Privacy settings as you illustrated. Worked perfectly.

I don’t know why I have not bumped into the Full Disk Access in Privacy before. I guess there is always a first time…

Now that I know this is not a Xojo issue, I should modify the name of this thread.

Thanks so much. I am going to get some rest…Whew…