You can make a remote WordPress site appear as a folder on your Mac, open it in VS Code, and save straight through to the running site. No upload step, no drag-and-drop, no FileZilla window.
There are three ways to do it, and on macOS in 2026 one of them is quietly broken.
This post covers all three, what each actually requires, and the cases where mounting is the wrong tool and you should use a shell instead.
Why not just use an SFTP client?
Because the loop is wrong. An SFTP client makes you download a file, edit a local copy, then remember to upload it.
Every step in that cycle is a chance to edit the stale copy, or to forget the upload and spend ten minutes debugging a change that never left your laptop.
It also cuts you off from your own tooling. You cannot run rg across the plugin directory, you cannot open the project in your editor with its language server working, and you cannot git diff what you just changed.
A mount fixes all of that by making the remote filesystem a path. Once the site is at ~/SandyWP/my-site, every local tool you already use works on it unmodified.
Option 1: Finder's Connect to Server
macOS can mount a WebDAV or SMB share natively. Open Finder, press Cmd+K, paste the server address, enter credentials, and the site appears in the sidebar.
This is what InstaWP's Local Mount does, and it is genuinely the lowest-friction option because you install nothing.
The catch is that Finder-mounted network volumes are slow for the operations developers actually do. A directory walk over WebDAV is a round trip per entry, so rg across wp-content or a VS Code file index can take minutes rather than seconds.
Finder also litters the remote filesystem with .DS_Store files, which is harmless on a throwaway site and irritating everywhere else.
Use it for editing a handful of known files. Do not use it as a project root.
Option 2: sshfs, which no longer installs cleanly on macOS
The classic answer is sshfs, which mounts anything you can reach over SSH. On Linux this still works fine: apt install sshfs, then sshfs user@host:/var/www/html ~/site.
On macOS it has stopped being a reasonable recommendation. sshfs needs FUSE, and the macOS FUSE implementation, macFUSE, is a kernel extension.
Homebrew cannot ship it. A macFUSE maintainer explained why in January 2025: kernel extensions must be code signed and notarized with a certificate only select developers have, and Homebrew's policy requires software that builds on the end user's machine.
So the macOS install path is a downloaded .pkg, an approval in System Settings under Privacy and Security, and a reboot. That is a rough first run for something you wanted in order to save time.
The modern alternative is FUSE-T, which implements the FUSE protocol in userspace and bridges it to a local NFS server. No kernel extension, no approval dialog, no reboot.
If you are setting this up by hand today, FUSE-T is the piece to install:
brew install --cask fuse-t
Option 3: one command, if the site is a sandbox
If the WordPress install is a SandyWP sandbox, the CLI does the whole thing in one command.
npm install -g @sandywp/cli
sandywp auth login
sandywp mount my-site
That mounts the sandbox's /var/www/html at ~/SandyWP/my-site. Use --path <directory> to put it somewhere else.
Then it is just a folder:
code ~/SandyWP/my-site
cd ~/SandyWP/my-site/wp-content/plugins
rg "add_action( 'init'"
Save a file, refresh the sandbox in your browser. That is the entire loop.
What it does under the hood, so you can judge it
It is SFTP over the SSH gateway, mounted with rclone, with FUSE-T or macFUSE providing the filesystem layer. Nothing exotic, and nothing you could not assemble yourself.
Two details are worth knowing because they change how it behaves.
The CLI manages its own rclone binary in ~/.sandywp/bin/. This is not empire-building: rclone's Homebrew build refuses to run rclone mount on macOS at all, so a system rclone installed by brew cannot be used here.
The mount uses an ephemeral SSH key scoped to that one sandbox, valid for 24 hours or the sandbox's remaining lifetime, whichever is shorter. It is not renewed automatically.
That expiry is deliberate. A key that opens exactly one disposable site for one day is a much smaller thing to lose than an account credential.
When it lapses, the mount goes stale rather than failing loudly, which is why there is a command to check:
sandywp mounts
sandywp unmount my-site
sandywp unmount --all
If sandywp mounts reports KEY EXPIRED or DEAD, unmount and mount again. unmount also deletes the key it issued.
Requirements, stated plainly
You install FUSE once per machine, as above. Linux needs fuse3 from your package manager instead.
Windows is not supported directly. Use WSL, or use SSH.
The sandbox has to be ready, owned by your account, and on a paid plan. Mounting is not on the free tier.
When a mount is the wrong tool
Mounting is for editing files. It is bad at three things, and reaching for it anyway is the most common way people end up frustrated with it.
Bulk operations. Untarring a large archive or running npm install inside a mounted folder means every file write is a network round trip. Do that over SSH instead, where the work happens on the machine that owns the disk.
Anything that is not a file. Database queries, WP-CLI, streaming debug.log while you reproduce a bug. sandywp ssh my-site --cmd "wp plugin list" answers those in one call, with no FUSE anywhere.
Production. This is a sandbox tool. Live-editing files on a real site through a mount, with no version control and a half-saved file visible to visitors, is how outages happen. Use a deploy pipeline, and use the sandbox as the place you get the change right first.
The short version
If you are on Linux, sshfs is still fine and takes one package.
If you are on macOS, do not start with sshfs. Install FUSE-T rather than macFUSE, and skip the kernel extension entirely.
If the site is a throwaway sandbox you are going to delete this afternoon, sandywp mount collapses the setup into one command and hands back a real folder with a key that expires on its own.
And if what you actually wanted was to run a command rather than edit a file, open a shell and skip all of this.
