@austinwendt Gatekeeper says that wp-cli.phar is signed with an Unnotarized Developer ID?
Thanks for digging in @emmtre ! and that does seem like an interesting idea!
Have you worked much with this codesigning stuff before? (I never had to until we started this last round of compiling PHP)
From your screenshot, it looks like the wp-cli.phar is signed, but not notarized – that’s probably the exact thing that’s preventing it from working.
As a test, can you try unsigning it? I think the general steps would look like:
- Quit local
- In terminal, navigate to the
wp-cli.pharfile on disk. - Unsign with the
codesigncommand
I think that should process would look like:
cd /Applications/Local.app/Contents/Resources/extraResources/bin/wp-cli
codesign --remove-signature ./wp-cli.phar
Can you give that a try and see if that gets things working @emmtre ?
@ben.turner No I haven’t been working at all with codesigning but I have been forced to learn when Apple has tightened the security of macOS.
Good idea but unfortunately it didn’t help to delete the signature from wp-cli.phar.
I did verify and tried different ways but the issue with Open site shell remains when you manually install Local app in macOS 13.0 Ventura.
I don’t think you will have this issue if you have installed Local app before updating to macOS 13.0 Ventura and are using the built-in update function in Local.
codesign -dv /Applications/Local.app/Contents/Resources/extraResources/bin/wp-cli/wp-cli.phar
Executable=/Applications/Local.app/Contents/Resources/extraResources/bin/wp-cli/wp-cli.phar
Identifier=wp-cli
Format=generic
CodeDirectory v=20200 size=262 flags=0x10000(runtime) hashes=1+5 location=embedded
Signature size=9059
Timestamp=1 Nov 2022 at 15:54:09
Info.plist=not bound
TeamIdentifier=UZR22399D3
Sealed Resources=none
Internal requirements count=2 size=220
sudo codesign --remove-signature /Applications/Local.app/Contents/Resources/extraResources/bin/wp-cli/wp-cli.phar
@ben.turner and @austinwendt and @afragen
The first workaround I found was to disable SIP (System Integrity Protection) but that’s not a viable or long-term solution. The second workaround is to delete the attributes com.apple.provenance and com.apple.quarantine from the Local app and then restart your machine. I can confirm that it works for me all the time. So it must be some sort of permission error with a component in Local app and Gatekeeper system in macOS
sudo xattr -d -rs com.apple.quarantine /Applications/Local.app
sudo xattr -d -rs com.apple.provenance /Applications/Local.app
2 Likes
I installed Local after upgrading to Ventura and opening the site’s .sh file from within User/…/Library/Application Support/Local/ssh-entry opens iTerm and shell commands work as expected.
1 Like
All that has worked all the time but the button “Open site shell” in Local doesn’t with Apple’s Terminal app set as default in Preferences. The error message that the shell script can’t be opened in Terminal is displayed by the Terminal app and not Local due to some permission error. Can you open a new terminal session by using the “Open site shell” button with iTerm set as default? I suspect you can since you are using another terminal app and not Apple’s Terminal app.
1 Like
I cam confirm that opening Site Shell works with iTerm but not with Terminal.app. Very strange.
A coworker just came to me with this problem as well. He installed LocalWP fresh on Ventura and has this problem. I cannot ask him to go through all this, his expertise lies elsewhere.
Would love a solution that does not feel hacky nor non-permanent, and I don’t have neither the time nor inclination to become tech-support for him.
Thing to note is that I have been using LocalWP for years and therefore had it before upgrading to Ventura and I have no problems at all.
Reading above, it looks like Terminal.app now has some additional security measures, but there is no section about Terminal in there (in the Privacy & Security tab)
Hope there is good news soon!
1 Like
Same issue. Now getting this error after upgrading to OSX Ventura 13.0.1 and the latest Local 6.5.2+6204 on Apple Silicon.
, above solution works for me after restarting the system.I recently switched from the intel version to the m1 arm64 version of LocalWP, and now I have this error as well.
Going through the list of solutions given above;
- Using nginx instead of Apache; doesn’t help (did not expect it to)
- Different PHP versions; doesn’t help (did not expect it to, either)
- unsigning wp-cli.phar; doesn’t help (again, did not expect it to, these three have nothing to do with opening the terminal and executing a shell-script.)
- using the path (click [i] and then the file) works, but defeats the purpose of a button
- disable SIP; refuse to do so, it worked for years with SIP enabled, so it should as well, now.
- Full Disk Access (to Local); doesn’t help
- Full Disk Access (to Terminal); already set, so no luck there
- removing com.apple.quarantine / com.apple.provenance ; doesn’t help for me.
- tcutil reset … ; doesn’t help either. (in fact, it doesn’t seem to affect anything at all)
I did verify and tried different ways but the issue with Open site shell remains when you manually install Local app in macOS 13.0 Ventura.
I don’t think you will have this issue if you have installed Local app before updating to macOS 13.0 Ventura and are using the built-in update function in Local.
My situation confirms this. Did not have the problem with the Local I had installed before upgrade to ventura, colleague of mine installed (the intel version) on a brand new notebook, and immediately had the problem. (and still has it after upgrading to the ARM64 version)
Macos ventura 13.0.1 on M1 Max
LocalWP ARM64 6.5.2+6204
Addendum: I switched back to the (backed-up) intel version of the app (mainly because of errors on the xdebug extension being built for the wrong architecture) , updated that to 6.5.2 as well, problems are gone, so somehow the “correct permissions” are remembered in the App, it must be some App attribute??? Well, don’t know, am not an App dev. But maybe this helps 
Thanx for trying out different solutions to verify the problem description. Weird it didn’t help for you since deleting the extended attributes from the Local app seems to work for most people. Did you restart the machine after running the xattr terminal commands?
Download iTerm and set that up as the default terminal app for Local. It works as expected, I don’t know why.
I can confirm that removing com.apple.quarantine / com.apple.provenance fixed the issue for me.
New install of local app ARM64 version on brand new M1.
I have the same problem. macOS Ventura 13.0.1
“ucJTkWnGs.sh” can’t be opened because (null) is not allowed to open documents in Terminal.
I had this same problem and did a lot of searching around to try to fix it . . . It started when I installed local for the first time. I had recently upgraded to ventura and I use iTerm2. I tried a lot of things to fix it: giving both iTerm and Terminal.app lots of permissions including full disk access and the abillity to run unsigned applications etc. I also set iTerm as the default application for all kinds of things, even for opening .sh and .bat files.
The solution I found made me feel kinda stupid, but here goes . . . I found setting in Local itself that determines what default terminal to use. Pretty sure it’s in Preferences >> Appearance and Behavior. I set that to iTerm and the next time I clicked “Open Site Shell” the error at the top of this thread DID NOT appear . . . however, my iTerm terminal just read the following line:
/Users/myName/Library/Application\ Support/Local/ssh-entry/yY_0dYVRi.sh; exit
and the command prompt was back to my default working directory. Seemed like it was doing nothing. So I searched around awhile for that issue and got nowhere. Then, out of the blue, I happened to click "Open site shell’ WHILE the other tab was already opened and viola, it worked as expected. The shell script executed and opened up on the public directory.
So, for people stuck on this: try and make sure that iTerm is set as your default terminal inside Local, and then try clicking “Open site shell” and then clicking it again. You may or may not need to give iTerm and terminal app all kinds of permissions on your system. I did not need to disable SIP. Weird, I know, but it worked for me. Hope it works for you.
Bug Summary
The “Open Site Shell” button is not working on my M1 Mac mini. When I click the button an error dialog pops up (see attached screenshot) which says “‘9MZJLjlMd.sh’ can’t be opened because (null) is not allowed to open documents in Terminal.”
Steps to reproduce
Open Local app, start a site, click on “Open Site Shell”
Environment Info
Describe your environment.
- M1 Mac Mini OS 13.1
- Default Nginx, PHP 7.4.30, MySQL 8.0.16
- Local 6.6.0+6231
- Terminal and Local both have Full Disk Access (settings/privacy and security/full disk access)
Supporting info
Please note there is an existing thread (not in bugs forum) from November where the user also has this issue:
http://community.localwp.com/t/please-help-me-i-opening-the-shell-via-the-open-site-shell-button-in-local-not-working/34499
Local Log
local-lightning.log (36.0 KB)
Screenshot
