PSA: After updating to macOS Tahoe 26, changes how SSH agent sockets should be mounted into Docker/OrbStack containers.

psa-macos-tahoe-26-container-ssh-agent-soocket-mount-change

# PSA: macOS Tahoe 26 changes how SSH agent sockets should be mounted into Docker/OrbStack containers.

After updating MacOS from 15.7.3 to 26.5.1, the update broke my existing setup for mounting SSH agent sockets to docker containers.

After updating to Tahoe, bind-mounting the host’s `SSH_AUTH_SOCK` path directly into a Linux container can stop working if you were pointing to the `launchd` socket path directly:

What used to work:

```bash
docker run \
  -v "$SSH_AUTH_SOCK:$SSH_AUTH_SOCK" \
  -e SSH_AUTH_SOCK="$SSH_AUTH_SOCK" \
  ...
```

That relies on mounting the macOS `launchd` socket path directly, often something like:

```bash
/var/run/com.apple.launchd.<id>/Listeners
```

After Tahoe 26.5.1, that path may still exist and work on the host, but it may not appear as a valid socket inside the container. The container sees `SSH_AUTH_SOCK`, but `test -S "$SSH_AUTH_SOCK"` fails, and tools like `ssh-add -l` cannot reach the agent.

The new working pattern on macOS is to mount the Docker runtime’s SSH agent proxy instead:

```bash
docker run \
  -v /run/host-services/ssh-auth.sock:/run/ssh-agent.sock:ro \
  -e SSH_AUTH_SOCK=/run/ssh-agent.sock \
  ...
```

This works with OrbStack and Docker Desktop. They expose `/run/host-services/ssh-auth.sock` as a stable proxy inside the Linux VM that follows the host’s active SSH agent. The container then gets a consistent internal path, `/run/ssh-agent.sock`, regardless of macOS changing the underlying `launchd` listener path.

Also: do not delete files under `/var/run/com.apple.launchd.*` or `/private/tmp/com.apple.launchd.*` as some Google results may suggest - it's not necessary. Those are system-managed sockets. The fix is to use the Docker/OrbStack host-services SSH proxy, not to clean up `launchd` listener files.