I wonder if there are any lurkers using 12.3.1 who’d care to check where the file is on their system.
I would, but I no longer have a 12.3.1, that went back to the user, who has had numerous issues with it (a few related to appleScript).
12.3.1, Intel. Results from Find Any File. Notice the dates for the two locations. Presumably Apple moved the file to a new location? (The line blurred out is the file location for another user added to the system in the past few weeks; the location matches the newer location on my user account.):
Thanks for the feedback. I created a new user and the file appeared in neither place, so it’s clearly not the valid test it used to be.
I started having the same problem, about one to two weeks ago. I have tried all of the above solutions, but without success. To answer Shane’s questions:
- I have used version 7 before installing version 8
- I am running MacOS version 12.3.1
- File permission error
- No error
•I have rebooted with System Preferences/Security & Privacy/Privacy/Full Disk Access as well as Accessibility unchecked, and then checked them without success.
•I have no SD7 application or files in ~/Library/Application Support
•I have downloaded a fresh version of SD8.
When I double click the SD icon, I receive a dialog that Script Debugger quit unexpectedly
Please help
When I ran the script through Terminal, it responded
/Applications/Script\ Debugger.app/Contents/MacOS/Script\ Debugger ; exit; alan@MacBook-Pro ~ % /Applications/Script\ Debugger.app/Contents/MacOS/Script\ Debugger ; exit; 2022-05-15 20:15:30.139 Script Debugger[7104:61384] <RKApplicationList: 0x6000005d3540>: _applicationsQueryGatheringFinished: NSConcreteNotification 0x6000030bd840 {name = NSMetadataQueryDidFinishGatheringNotification; object = <NSMetadataQuery: 0x600001e0d300>} 2022-05-15 20:16:33.746 Script Debugger[7104:61384] Could not find image named 'RKPaid'. zsh: segmentation fault /Applications/Script\ Debugger.app/Contents/MacOS/Script\ Debugger
Might the lack of an image RKPaid be the problem for my SD8 opening problem?
If so, how can I correct this issue, as I had already paid for the SD 7 to 8 upgrade?
The Full Disk Access issue causes the dialog to appear, but it does not cause Script Debugger to quit. You have a different – and more serious – problem.
Please download a new copy of Script Debugger, and also do a system restart.
I faced this issue today, after updating to macOS 12.5 beta2 ?(21G5037d).
System requested to get Full Disk Access with SD8.
Though I did as system requested, but SD8 didn’t get the Full Disk Access rights.
After rebooting, this issue was cleared. It is very strange behavior…
Hi @ShaneStanley,
I’m reviving this thread because I’m experiencing the issue on a fresh macOS 12.6 installation, have identified the cause, and believe that the issue can only be properly fixed by an update to Script Debugger.
This is an issue that will affect anyone launching SD8 on clean installations of macOS ≥12.3, causing repeated spurious “Full Disk Access Required” warning messages.
The Problem:
I just installed Script Debugger 8 on a brand new Mac (macOS 12.6) & added it successfully to the Full Disk Access list in System Preferences. However, I kept getting the following dialog every time I launched the application (and didn’t want to just silence the dialog):
I spent a lot of time with reboots & adding/removing the application from the Full Disk Access list, before realizing that Script Debugger DID have Full Disk Access already, and that the dialog was incorrect.
This was evidenced by the fact that scripts could access /Library/Preferences/com.apple.TimeMachine.plist
without error, a path protected by SIP/Full Disk Access.
-- Throws an error if the running application does not have Full Disk Access.
do shell script "cat /Library/Preferences/com.apple.TimeMachine.plist"
The Cause:
I then stumbled upon a forum post here, where Shane suggested that Script Debugger checks for Full Disk Access by attempting to read ~/Library/Containers/Safari/CloudTabs.db
.
As noted by me here, the database was moved to ~/Library/Containers/com.apple.Safari/Data/Library/Safari/CloudTabs.db
with the release of macOS 12.3 (thanks, Apple ).
On existing macOS installations, the (stale) database file was left at the old path (~/Library/Containers/Safari/CloudTabs.db
) when upgrading to macOS 12.3. On new macOS installations, however, there will not be a file at this location, causing the SD8’s Full Disk Access test to fail erroneously.
As for me, I found that creating an empty file at ~/Library/Containers/Safari/CloudTabs.db
stops the dialog from appearing in Script Debugger. Hooray!
The Solution:
For The Developers:
Script Debugger must update how it checks for Full Disk Access, since new macOS installations will not have a file at ~/Library/Containers/Safari/CloudTabs.db
.
I would suggest checking for read access to:
/Library/Preferences/com.apple.TimeMachine.plist
It’s protected by SIP, and as far as I know it always exists (even if Time Machine has not been configured).
For End-Users of Script Debugger 8.0.5 & Earlier:
If you’re sure Full Disk Access is working (the above AppleScript runs without error), you can hide the dialog by checking “Don’t ask again”. However, this means that you won’t be notified if a system update or other bug causes Script Debugger to lose Full Disk Access.
You can instead use the following Terminal commands to resolve the issue, until a fix is available in a future version of Script Debugger.
-
Create an empty file at the path where Script Debugger 8 expects one to exist:
touch ~/Library/Containers/Safari/CloudTabs.db
-
If you have previously checked the “Don’t ask again” checkbox on the above dialog, and wish to re-enable the dialog:
defaults delete com.latenightsw.ScriptDebugger8 prefSuppressFullDiskAccessWarning
Summary:
- Script Debugger ≤8.0.5 checks for read access to
~/Library/Containers/Safari/CloudTabs.db
to determine if Full Disk Access has been granted. - This file only exists on systems that had previously run a version of macOS <12.3. Clean installations of macOS ≥12.3 do not have this file.
- Script Debugger 8.0.5 must be updated by the developers to fix the “Full Disk Access Required” appearing erroneously when the above file does not exist.
- End-Users can temporarily address the issue by creating an empty file at the above path.
We do test for that path, but if it’s not there we look for a different path.
Unfortunately there’s another issue, which is that even with full disk access and the file found, sometimes access is not granted. That’s why we added the Do Not Show again
checkbox. It’s not a great solution, but in the absence of an official method, it’s about the best we can do.
This happens rarely for me, and I don’t click the Do not show again
checkbox, because if SD does not have full disk access, that’s a problem.
So, are you saying it does, but doesn’t think it does?
When I go to Security Preferences it seems to be turned off.
Sometimes, on some Macs. Sorry for sounding so vague, but that’s unfortunately the nature of the issue.
Fair enough, when it happens lemme know if there’s anything I can do to help track it down.
Maybe you could add a help button to the dialog, which will lead to a more detailed explanation, so that everyone is aware of this highly random situation?
Thanks for getting back to me. I’m familiar with the other issue you’re describing (which appears to be what originally started the thread), and that it’s due to something buggy with the system frameworks. From what I understand, though, that issue:
- Is intermittent
- Involves macOS not reliably giving FDA to Script Debugger, regardless of whether
CloudTabs.db
exists at the old location (and involves some sort of TCC de-authorization bug)
The issue I’m describing starts partway down the thread, is specific to macOS ≥12.3, and:
- Is reproducible
- Involves Script Debugger displaying the “FDA Required” if
~/Library/Containers/Safari/CloudTabs.db
does not exist - Appears to be reliably solved by manually creating the “missing”
CloudTabs.db
file
Unless I’m missing something (definitely possible :D), they are separate issues, and the latter may be a logic error with how SD8 checks the FDA-gated paths. If I’m correct, this will continue to be an issue for all future SD installations on new macOS installations. Most people probably just click the “Don’t ask again” checkbox (which makes the FDA check useless anyway!).
Regardless, it took me a couple of hours to resolve the issue on my end, since I was familiar with the intermittent FDA issues, but was not expecting the CloudTabs.db
issue (even though I was coincidentally familiar with the macOS 12.3 path change).
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.
On Ventura (latest beta), a reboot solves the issue of repeated FDA requests.
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.
I guess I was too hasty. My solution didn’t work, even the tip with touch doesn’t work for me.