[Bug]: The SSH flag for running containers doesn't update when the variable changes.

[vibbix]

I have done the following

• I have searched the existing issues
• If possible, I've reproduced the issue using the 'main' branch of this project

Steps to reproduce

1. Use a setup that requires some kind of forwarding agent (like 1Password).
2. Have a SSH Config like this:

Host *
	IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"

3. In terminal:

❯❯ ~  12:58 echo $SSH_AUTH_SOCK
/private/tmp/com.apple.launchd.sOMZW8wQ8o/Listeners
❯❯ ~  12:59 export SSH_AUTH_SOCK="$HOME/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"
❯❯ fix_docker_build git:(main) 13:00 container run -it --rm --ssh --uid 0 alpine:latest sh
/ # apk add openssh-client
(1/6) Installing openssh-keygen (10.2_p1-r0)
(2/6) Installing ncurses-terminfo-base (6.5_p20251123-r0)
(3/6) Installing libncursesw (6.5_p20251123-r0)
(4/6) Installing libedit (20251016.3.1-r0)
(5/6) Installing openssh-client-common (10.2_p1-r0)
(6/6) Installing openssh-client-default (10.2_p1-r0)
Executing busybox-1.37.0-r30.trigger
OK: 12.8 MiB in 22 packages
/ # ssh-add -l
The agent has no identities.
/ # ^C

/ # exit
❯❯ fix_docker_build git:(main)  13:00 echo $SSH_AUTH_SOCK
/Users/vibbix/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock
❯❯ fix_docker_build git:(main) 13:00 container run -it --rm --ssh --uid 0 alpine:latest sh
❯❯ fix_docker_build git:(main)  13:01 container run -it --rm --volume "${SSH_AUTH_SOCK}:/run/host-services/ssh-auth.sock" --env "SSH_AUTH_SOCK=/run/host-services/ssh-auth.sock" --uid 0 alpine:latest sh

/ # apk add openssh-client
(1/6) Installing openssh-keygen (10.2_p1-r0)
(2/6) Installing ncurses-terminfo-base (6.5_p20251123-r0)
(3/6) Installing libncursesw (6.5_p20251123-r0)
(4/6) Installing libedit (20251016.3.1-r0)
(5/6) Installing openssh-client-common (10.2_p1-r0)
(6/6) Installing openssh-client-default (10.2_p1-r0)
Executing busybox-1.37.0-r30.trigger
OK: 12.8 MiB in 22 packages
/ # ssh-add -l
256 SHA256:/********** Example Key (ED25519)
/ #

Current behavior

The SSH_AUTH_SOCK isn't set to the correct one.

Expected behavior

The changed SSH_AUTH_SOCK should be picked up right away, as is mentioned in the documents here

Environment

❯❯ ~   13:04 xcodebuild -verbose
Command line invocation:
    /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -verbose

2026-02-10 13:04:38.028 xcodebuild[20474:140370]  DVTErrorPresenter: Unable to load simulator devices.
Domain: DVTCoreSimulatorAdditionsErrorDomain
Code: 3
Failure Reason: The version of the CoreSimulator framework installed on this Mac is out-of-date and not supported by this version of Xcode.
Recovery Suggestion: Please ensure that you have installed all available updates to your Mac's software, and that you are running the most recent version of Xcode supported by macOS.
--
CoreSimulator is out of date. Current version (1048.0.0) is older than build version (1051.17.7).
Domain: DVTCoreSimulatorAdditionsErrorDomain
Code: 3
--

2026-02-10 13:04:38.028 xcodebuild[20474:140370]  iOSSimulator: [SimServiceContext sharedServiceContextForDeveloperDir:error:] returned nil (Error Domain=DVTCoreSimulatorAdditionsErrorDomain Code=3 "CoreSimulator is out of date. Current version (1048.0.0) is older than build version (1051.17.7)." UserInfo={NSLocalizedDescription=CoreSimulator is out of date. Current version (1048.0.0) is older than build version (1051.17.7).}). Simulator device support disabled.
2026-02-10 13:04:38.077 xcodebuild[20474:140311] Writing error result bundle to /var/folders/db/68jc7cyn66jcjmdnss8qlw1r0000gn/T/ResultBundle_2026-10-02_13-04-0038.xcresult
xcodebuild: error: The directory /Users/vibbix does not contain an Xcode project.

❯❯ ~   13:04 sw_vers
ProductName:		macOS
ProductVersion:		26.2
BuildVersion:		25C56
❯❯ ~  13:04 brew info containers
Error: No available formula with the name "containers". Did you mean container?
❯❯ ~   13:04 brew info container
==> container ✔: stable 0.9.0 (bottled), HEAD
Create and run Linux containers using lightweight virtual machines
https://apple.github.io/container/documentation/
Installed
/opt/homebrew/Cellar/container/0.9.0 (19 files, 222.6MB) *
  Poured from bottle using the formulae.brew.sh API on 2026-02-09 at 12:43:43
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/c/container.rb
License: Apache-2.0
==> Requirements
Build: Xcode >= 26.0 (on macOS) ✔
Required: arm64 architecture ✔, macOS >= 26 (or Linux) ✔, macOS ✔
==> Options
--HEAD
	Install HEAD version
==> Caveats
To restart container after an upgrade:
  brew services restart container
Or, if you don't want/need a background service you can just run:
  /opt/homebrew/opt/container/bin/container system start
==> Analytics
install: 2,796 (30 days), 6,089 (90 days), 7,693 (365 days)
install-on-request: 2,795 (30 days), 6,083 (90 days), 7,688 (365 days)
build-error: 4 (30 days)
❯❯ ~  13:04 container system status
apiserver is running
application data root: /Users/vibbix/Library/Application Support/com.apple.container/
application install root: /opt/homebrew/Cellar/container/0.9.0/
container-apiserver version: container-apiserver version 0.9.0 (build: release, commit: unspeci)
container-apiserver commit: unspecified
❯❯ ~  13:05

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct

[chavezMac]

Hey @vibbix, I think I may have found a potential fix for the issue.

The --ssh flag was persisted only as a boolean, not as the caller's resolved socket path. At container bootstrap, SandboxService was resolving the host socket from the runtime helper process environment:

• ProcessInfo.processInfo.environment["SSH_AUTH_SOCK"]

Because the helper is launched via launchd, that usually reflects the launchd/runtime environment, not the interactive shell that ran container run. (Apple’s Daemons and Services Programming Guide states that “launchd configures the operating environment for the daemons that it manages”; the helper’s env comes from what launchd provides, not from the shell that triggered the launch.)

Result: A valid socket mount could be created, but from the wrong agent socket.

The potential fix I made was to pick the socket path in a fixed order. In SandboxService, we now check (in order):

1. config.sshAuthSocketPath (if present and a valid Unix socket)
2. Runtime helper env SSH_AUTH_SOCK (if a valid Unix socket)
3. launchctl getenv SSH_AUTH_SOCK (if a valid Unix socket)

With that, I was able to run a container and see the correct 1Password SSH key. I still need to run the full flow described in the documentation: stop the container, log out, log back in, and restart the container, to confirm the system updates the socket mount target to the new SSH_AUTH_SOCK value.

[JaewonHur]

@chavezMac Thanks, it looks more intuitive.
Could you make a PR later if you have a time? :)

[chavezMac]

@JaewonHur submitted a PR!