Problem
macOS volume mounts depend on sshfs, which on macOS means the macfuse cask plus gromgit/fuse/sshfs-mac — the combination both our troubleshooting docs and our CI (.github/actions/install-dependencies/action.yaml) install today. That foundation is crumbling:
gromgit/fuse/sshfs-mac was deprecated and disabled upstream on 2026-02-11 because it is no longer maintained. Homebrew still installs it during the grace period and warns on every install (visible as annotations on every macOS CI job, e.g. this release run); at some point the install will hard-fail, breaking both CI and any user following our docs.macfuse requires loading a kernel extension, which on modern macOS means a trip through Privacy & Security approval and a reboot — a rough first-run experience — and it is closed source.
The warning annotations are currently suppressed on the CI side (see the "Silence the expected Homebrew annotations" commit on the 2.30.0 release branch), but that is a stopgap, not a fix.
Proposal
Migrate to FUSE-T, a kext-less FUSE implementation for macOS (it bridges to a local NFSv4 server instead of a kernel extension: no kext approval, no reboot), together with its maintained sshfs build:
$ brew tap macos-fuse-t/homebrew-cask
$ brew install fuse-t fuse-t-sshfs
Scope
Notes
FUSE-T's sshfs is a fork of the same sshfs codebase, so option compatibility is expected but must be verified, not assumed. If some option behaves differently, the invocation in sftp.go can branch on the FUSE flavor.
Problem
macOS volume mounts depend on
sshfs, which on macOS means themacfusecask plusgromgit/fuse/sshfs-mac— the combination both our troubleshooting docs and our CI (.github/actions/install-dependencies/action.yaml) install today. That foundation is crumbling:gromgit/fuse/sshfs-macwas deprecated and disabled upstream on 2026-02-11 because it is no longer maintained. Homebrew still installs it during the grace period and warns on every install (visible as annotations on every macOS CI job, e.g. this release run); at some point the install will hard-fail, breaking both CI and any user following our docs.macfuserequires loading a kernel extension, which on modern macOS means a trip through Privacy & Security approval and a reboot — a rough first-run experience — and it is closed source.The warning annotations are currently suppressed on the CI side (see the "Silence the expected Homebrew annotations" commit on the 2.30.0 release branch), but that is a stopgap, not a fix.
Proposal
Migrate to FUSE-T, a kext-less FUSE implementation for macOS (it bridges to a local NFSv4 server instead of a kernel extension: no kext approval, no reboot), together with its maintained sshfs build:
Scope
pkg/client/remotefs/sftp.goworks againstfuse-t-sshfs. Two spots deserve attention: the IPv6 path uses-o slavewith a stdin/stdout connection, and the IPv4 path uses-o directport; both need to behave identically under FUSE-T. Unmount handling on macOS should also be exercised..github/actions/install-dependencies/action.yamlfrommacfuse+gromgit/fuse/sshfs-mactofuse-t+fuse-t-sshfs, and drop the now-unneeded annotation suppression for the deprecated install.docs/troubleshooting.md(which currently walks users through the deprecated tap) and any install/quick-start mentions of macfuse.Notes
FUSE-T's sshfs is a fork of the same sshfs codebase, so option compatibility is expected but must be verified, not assumed. If some option behaves differently, the invocation in
sftp.gocan branch on the FUSE flavor.