Open Site Shell not working macOS Big Sur

@ben.turner it seems that Local never cleans up deleted sites, consequently this script can become quite unwieldy with all the results. But thanks, as it works. <3

1 Like

Oof. I can see how that gets ugly. I don’t have a fix, but doing a little CLI monkeying around with jq, I can see that at the very least on my machine, I don’t have any orphans – ie, shell scripts that don’t have a corresponding entry in the sites.json file:

Maybe some of these commands can help others with cleanup?

cd ~/Library/Application\ Support/Local
ls ssh-entry
ls run # each local site's runtime environment
jq -r 'keys[]' sites.json
comm \
        <(jq -r 'keys[]' sites.json | sort) \
        <(find ssh-entry -maxdepth 1 -mindepth 1 -type f -name '*.sh' | sed -E 's/ssh-entry\/(.*).sh$/\1/' | sort)

But that cleanup definitely would get tedious, so it might be easier to nuke everything and start over – which is what I end up doing every month or so with the amount of QA I do related to odd, broken sites.

Note, that comm can be used to only show one of those “columns” so to only see entries that only exist in that second list (ie .sh files), you should be able to do something like this to “suppress the first and third columns”:

comm -13 \
        <(jq -r 'keys[]' sites.json | sort) \
        <(find ssh-entry -maxdepth 1 -mindepth 1 -type f -name '*.sh' | sed -E 's/ssh-entry\/(.*).sh$/\1/' | sort)

Again, none of this actually cleans anything up, it just is meant to help you zero in on what might not actually exist anymore.

For the feature request, removing the specific site shell scripts on a Delete of the site would be great.

Any ETA of ‘Open Site Shell’ fix for Big Sur?


Bumping this. Also wondering if this will be fixed soon.

I’m experiencing this issue as well. Clicking on ‘Open Site Shell’ doesn’t do anything, visually at least.

This is the biggest issue I’m having with Big Sur and on Apple Silicon.

Thanks for all the comments and adding your voices to this thread.

The team has been fixing a few other bugs and implementing a few features that should make Local easier to extend so we don’t have a specific ETA for when this issue with opening the site-shell will be fixed. We’ll be sure to update this thread when a fix has been released!


Are there any updates about it?

1 Like

@ben.turner Are “new features” more important than fixing broken functionality? That seems backwards? There are several large issues that are not being fixed (this issue, macOS database connection, Imagick not installed) to prioritize new functionality, and that’s very disappointing. Please prioritize the fixing of existing yet broken functionality before introducing new features.

Hi @ben.turner and team, are there any updates on this? Anything you need us to help with in order to get a resolution to this issue?

Thanks everyone for your patience with this!

Thanks for offering to help! There’s not anything that can be done except wait a bit more while the team finishes up the fix and does some final QA.

They’re both important! :larry:

I know that it feels like there isn’t movement here with the Big Sur terminal issue, but it’s always hard trying to balance priorities of new features against bugs caused by changes to the underlying technology. Part of the issue with the Big Sur update is that it’s a new version of an OS. We’re devs too, and are hesitant to dive into a new OS the day that it’s released in case it breaks things and prevents us from working on Local.

The good news is that we have virtual machines and have the tooling to help work on the various OSes, but it does take time to account for all the different architectures that Local abstracts away.

This Big Sur terminal issue is definitely frustrating – even for me as a heavy terminal user, but there is a workaround for getting access to the sites’ shell. When one compares this issue against other issues that don’t have workarounds, or which affect more users than those running just one version of one OS, the team will likely prioritize the issue that has a larger impact.

An example of those kinds of issues would be one that you mention: not having imagemagik compiled for a specific version of PHP.

All that’s to say that we know the current workaround for opening a site shell in Big Sur sucks, but we have everything we need to fix it, as well as a version that’s almost ready to be released!

Only a few minor edits and this solution is great.

If using Local Beta you will also need to adjust the path to change /Local/ to /Local Beta/.


Thought I’d add my solution/work around here, I’ve almost always used this method as opposed to the “Open Site Shell” option, even pre-Lightning.

WP CLI allows you to add your own settings while running it, by adding a wp-cli.local.yml and wp-cli.local.php file to your WP root directory.

In the wp-cli.local.yml file add:

  - wp-cli.local.php

In the wp-cli.local.php file add:

  define( 'DB_HOST', 'localhost:/Users/yourusername/Library/Application Support/Local/run/o-woLHJD_/mysql/mysqld.sock' );

  error_reporting( E_ERROR );
  define( 'WP_DEBUG', false );

You shouldn’t need to define the DB_USER or the DB_PASSWORD since it will inherit them from the wp-config.php. However, if you do need them, then just copy it from wp-config.php and define them in this file too.

Also, you don’t HAVE to add the error report or debugging lines, but if you don’t it will constantly squawk at you that the constants are already defined, amongst all other notices, not relevant to WP-CLI, it might kick out.

If you’re using the non-Lightning version, just replace the socket path with the IP and Socket, e.g. 111.222.333.444:5678

You should then be able to open terminal regularly (not Open Site Shell), path into your WP install and then use WP CLI as you normally would.

1 Like

Wanted to let this topic know that the latest Local Release should fix the “Open Site Shell” issue under Big Sur:

@ben.turner When will the update show in Local Beta? Currently on 5.9.5 and reports as up to date.


Thank you so much for following up on this thread for so long. This is a very important issue for someone like me, because I really don’t use local for WordPress development, I use it for craft CMS development. Because of that open site shell is a very useful feature for me to install composer and anything else I need on that. This is some thing that I love about Local, it has a very good UI that I’m able to go in and build a great website with a different CMS other than word press but still get the great benefits of local. Thank you so much.

1 Like

This is one of those unseen “features” that the team has been working on, namely improving the release process so that it doesn’t take someone a full day to package up and release things. There’s possibly a bug or two here, but here’s the general gist:

  • Local Stable and Beta versions are released and pushed up to the servers
  • Users can manually download and install those versions
  • After a bit of time (usually about a week) we release to the “autoupdater” which is basically a place where your version of Local can as “Is there an update?”

The reason that we stagger updating to the autoupdater is so that if there is a very serious bug that was missed in QA, it’s only experienced by users that actively install the latest version.

Still, I’m sure there are areas of improvement in all of this process, so thank you all for caring and helping to report issues like this – it really makes Local better!

1 Like

Just to report that Open Site Shell now works in Big Sur with Local 5.9.6

1 Like

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.