[Bug]: Desktop SSH remote's managed server inherits a per-session forwarded SSH_AUTH_SOCK that dies with the launching session

From the Clanker:

Context: follow-up to #10179, which covered the systemd service. This report is the other Linux surface: the desktop app's SSH remote, which launches its own managed t3 serve over ssh and never touches systemd. It hits the same Permission denied (publickey) failure for a different reason: the server inherits the launching session's forwarded agent socket, and that socket is removed when the session ends. The reporter has a dotfiles workaround (below) but it only applies to hosts with a persistent agent socket.

Before submitting

• I searched existing issues and did not find an exact duplicate.
• I included enough detail to reproduce or investigate the problem.

Related: #10179 (systemd service has no SSH_AUTH_SOCK at all), #3067 (devcontainer server started before the forwarded socket exists), #5740 (WSL). This report is about the desktop SSH remote with remoteServerKind: managed, where the socket is present at launch but is a per-session forwarded path that stops existing shortly after.

Area

apps/desktop

Steps to reproduce

1. On the local machine, set ForwardAgent yes for the remote host in ~/.ssh/config (ssh_config defaults this to no, so it is an opt-in). Leave the remote sshd at its default AllowAgentForwarding yes.
2. On the remote (Linux), use a repository whose origin is a GitHub SSH URL. Do not export SSH_AUTH_SOCK from any shell rc file, so the only agent socket a non-interactive ssh session sees is the forwarded per-session one sshd creates. On this host (OpenSSH 10.5p1) that is under ~/.ssh/agent/.
3. Add the host as an SSH remote in the desktop app and connect. The desktop launches the managed server through ~/.t3/ssh-launch/<stateKey>/run-t3.sh and detaches it (the process ends up reparented to PID 1).
4. Let the launching ssh session close.
5. Open the repository in T3 Code and click pull, or wait for the background remote-status fetch.

Expected behavior

The managed server keeps working SSH agent access for as long as it runs, or the launch resolves a stable agent socket instead of the one tied to the launching session.

Actual behavior

Pull fails with:

Git command failed in GitVcsDriver.pullCurrentBranch.pull (/home/<user>/src/<repo>): git pull failed

The remote server.log also shows the background poller failing repeatedly (20 fetchRemoteForStatus entries):

GitCommandError: Git command failed in GitVcsDriver.fetchRemoteForStatus (/home/<user>/src/<repo>): Background Git fetch exited with a non-zero status.
    at statusDetailsRemote (file:///home/<user>/.t3/runtime/versions/0.0.41-nightly.20260915.1752/t3:256742:34)
    ...
    at VcsStatusBroadcaster.retainRemotePoller (file:///home/<user>/.t3/runtime/versions/0.0.41-nightly.20260915.1752/t3:258129:10)

/proc/<pid>/environ of the managed server:

SSH_AUTH_SOCK=/home/<user>/.ssh/agent/s.SUIjO4iobl.sshd.U1DmzQ0mYB

That path no longer exists. ls on it returns No such file or directory, and ssh-add -l against it returns Error connecting to agent: No such file or directory. The only sockets still present in ~/.ssh/agent/ belong to later ssh sessions.

Running git with the server's exact socket reproduces the failure; running it with any live agent socket succeeds:

SSH_AUTH_SOCK=/home/<user>/.ssh/agent/s.SUIjO4iobl.sshd.U1DmzQ0mYB git pull
# git@github.com: Permission denied (publickey).
# fatal: Could not read from remote repository.

The desktop relaunches the managed server on reconnect, and each relaunch picks up a fresh per-session socket, so the problem comes back as soon as that session closes again. Two relaunches today (05:26 and 05:36) both ended up with dead socket paths.

Impact

Major degradation or frequent failure: pull, fetch, and the background remote status all fail for SSH remotes until the server is restarted, and a restart only helps until the launching session closes.

Version or commit

Desktop and managed archive: 0.0.41-nightly.20260915.1752

Environment

• Local: macOS desktop app, ForwardAgent yes for the host in ~/.ssh/config
• Remote: Arch Linux ARM in OrbStack, aarch64, sshd with AllowAgentForwarding yes, login shell zsh
• Remote server launched by the desktop SSH remote (runner: archive, remoteServerKind: managed), tunneled to remote port 3774
• A separate t3code.service systemd instance on port 3773 with the #10179 drop-in was running on the same host and was unaffected, because the desktop's SSH remote does not use it

Logs or stack traces

# desktop.trace.ndjson
ssh.remoteServer.launch.start {"alias":"mbp24dev","runner":"archive","archiveVersion":"0.0.41-nightly.20260915.1752","stateKey":"9c2f9984ac7eff72"}
ssh.tunnel.ready {"command":["ssh","-o","BatchMode=yes","-o","ConnectTimeout=10","-p","22","-o","ExitOnForwardFailure=yes","-o","ControlMaster=no","-o","ControlPath=none","-o","ControlPersist=no","-o","ServerAliveInterval=15","-o","ServerAliveCountMax=3","-n","-N","-L","49753:127.0.0.1:3774","jh@mbp24dev"]}
ssh.environment.ensure.succeeded {"localPort":49753,"remotePort":3774,"remoteServerKind":"managed","issuedPairingToken":true}

# remote: managed server process
$ ps -o pid,ppid,lstart,args -p 2684763
2684763 1 Tue Sep 15 05:26:29 2026 /home/jh/.t3/runtime/versions/0.0.41-nightly.20260915.1752/t3 serve --host 127.0.0.1 --port 3774 --base-dir /home/jh/.t3
$ tr '\0' '\n' < /proc/2684763/environ | grep ^SSH_AUTH_SOCK=
SSH_AUTH_SOCK=/home/jh/.ssh/agent/s.SUIjO4iobl.sshd.U1DmzQ0mYB
$ ls -la /home/jh/.ssh/agent/
srw------- 1 jh jh 0 Sep 14 19:52 s.SUIjO4iobl.sshd.PGcZvniObu
srw------- 1 jh jh 0 Sep 15 05:29 s.SUIjO4iobl.sshd.iEWCpn4Oc4

Workaround

Export a stable agent socket from the remote's zsh startup so the launch shell overrides the forwarded one. On OrbStack:

# ~/.zshenv
if [[ -S "/opt/orbstack-guest/run/host-ssh-agent.sock" ]]; then
  export SSH_AUTH_SOCK="/opt/orbstack-guest/run/host-ssh-agent.sock"
fi

Then kill the managed t3 serve so the desktop relaunches it. After that the new process had the OrbStack socket in its environment and fetch/pull worked. This only helps on hosts that have a persistent agent socket to point at, which is not the general case for an SSH remote.

Suggested fix

The managed launch should not depend on the launching session's forwarded socket outliving the session. Options, in rough order of preference:

• Keep a long-lived ssh session (or the tunnel session itself, with -A) as the owner of the forwarded agent, and point the managed server at that session's socket, re-resolving it on reconnect.
• Or expose the socket path through a stable symlink the launch script maintains (for example ~/.t3/ssh-launch/<stateKey>/agent.sock re-linked on each connect) and set SSH_AUTH_SOCK to the symlink.
• Or at minimum, detect a dead SSH_AUTH_SOCK before running git and surface the underlying Permission denied (publickey) stderr instead of git pull failed.

Start with the desktop SSH remote launch flow and the generated ~/.t3/ssh-launch//run-t3.sh, using the ssh.remoteServer.launch and ssh.tunnel trace entries as entry points. Reproduce with ForwardAgent enabled, then inspect how SSH_AUTH_SOCK is passed to the detached managed server after the launching session closes. Done means the managed server retains usable agent access for its lifetime or reports the underlying agent failure clearly.