The problem, I think, is that when you manually create that file, it works because you created it, and it’s no longer used as a file by the system. Without it, we go in to check for the file in it’s new path, and if we can’t get access there, we flag the potential issue.
In other words, I think you’re just effectively bypassing Script Debugger’s check, and not really addressing the problem.
One other point I should mention: the sort of drastic problems evident (and forecast) when this security stuff was first implemented have turned out to be either bugs that have been fixed or simply over pessimistic. So your response, or even just clicking the Don’t Show Again box, don’t seem to be causing any problems we’re hearing about. At least so far.
I’m not sure that’s the case; as I said above, the script I was running to test tries to read /Library/Preferences/com.apple.TimeMachine.plist and will throw an error if FDA is not granted. SD was persistently giving me the “FDA Required” dialogs even though:
The script (and therefore Script Debugger) did have FDA, as it could run without error
I had a CloudTabs.db file at the new location
I never had issues with FDA being granted by macOS, but the SD8 but the dialog was persistent until I created CloudTabs.db at the old location.
That’s good to hear. I appreciate your responsiveness on the thread & will leave the discussion here. I just wanted to make sure you guys were aware of the specific issue with the missing old CloudTabs.db, as it may become more of an issue as more people have fresh installs of macOS ≥12.3.
These kinds of threads tend to get bogged down by multiple related issues, but it is helpful to know that the “FDA Required” dialog may mislead if ~/Library/Containers/Safari/CloudTabs.db does not exist on the system. Saves some troubleshooting time.
I’ve solved this issue by removing SD8 (current Beta) from Accessibility and Full Disk Access. Then I deleted the App and restarted the Mac. I installed SD again and the dialog on launch only appeared once. Before this procedure SD8 never appeared automatically in the list of Full Disk Access, even after messing with tccutil.
What worked for me (on a new Ventura system) was to make a copy of CloudTabs.db, taking the file from ~/Library/Containers/Safari/Data/LibrarySafari and copying it to ~/Library/Safari. macOS wouldn’t let me simply touch the file into existence
If you weren’t able to touch the file into existence, then Terminal itself (or whatever ran the command) did not have Full Disk Access and could not therefore bypass the SIP filesystem protections.
Manually creating the file through the GUI should work just as well, though.
Manually creating the ~/Library/Safari/CloudTabs.db file (after creating the Safari directory itself) didn’t resolve the issue, unfortunately. However the test
do shell script "cat /Library/Preferences/com.apple.TimeMachine.plist"
passes just fine, and I verified that it doesn’t pass if I revoke FDA to SD8. (I wanted to insure that terminal having FDA might allow a shell run to pass even if SD didn’t have permission; nope, the checks are smarter than that) so I guess I’m just gonna grit my teeth and tell the popup not to show again. Goes against my nature but I don’t know what more to do after doing deletes and reboots etc.
I’ve encountered this on a new computer running Ventura 13.2. The CloudTabs.db file does not exist, and I haven’t received any file-save errors. I removed and added Script Debugger to Accessibility and Full Disk Access in Privacy and Security. I did a reboot before and after but still got the dialog. I checked the don’t ask again box and that seems to do the job.
I was having the same problems as listed here on a new Mac running Ventura 13.0.1. I haven’t used SDB in a long time, and it’s a new Mac, so no v.7 ever on the machine. This solution worked perfectly. Otherwise everything else here didn’t work. I was unable to save files except as Text if ignoring the dialog box.
I had to set up Script Debugger 8 on a fresh Mac again (macOS 12.6.5), and ran into the same issue once more. However, there was some confusion above regarding the path for the file.
The correct path to fix the issue is: ~/Library/Safari/CloudTabs.db
Note the lack of Containers intermediary folder. My apologies for any confusion – unfortunately, I can no longer edit the above posts to provide the correct path.
The correct shell command is: touch ~/Library/Safari/CloudTabs.db
Note that whatever is running the shell command (i.e. Terminal) must itself have Full Disk Access for the above to work. Alternatively, use Finder.
SD 8 crashes before I can even get the popup about Full Disk Access. I used to get the popup, but after uninstalling SD 8 and reinstalling it, now it crashes right away.
This will work only for users that have previously enabled iCloud support for Safari (most users, I’d imagine), but will also create a permanent snapshot of the current iCloud Tabs database, which people may not want for privacy reasons.
This issue arises because the iCloud Tabs database was moved to the containerized path in macOS 12.3 (presumably for privacy reasons), but Script Debugger 8 still uses the old path as a test for Full Disk Access. Creating an empty file at this location is all that is needed, since Safari no longer accesses the old path.
Because this seems to be such a frequent & recurring issue, I want to reiterate for future users:
The most straightforward shell command is: touch ~/Library/Safari/CloudTabs.db
Note that whatever is running the shell command (i.e. Terminal) must itself have Full Disk Access for the above to work.
