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

openedSep 15, 2026byJJacob Hands

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

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.
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/.
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).
Let the launching ssh session close.
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:

text

1	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):

text

1	GitCommandError: Git command failed in GitVcsDriver.fetchRemoteForStatus (/home/<user>/src/<repo>): Background Git fetch exited with a non-zero status.
2	at statusDetailsRemote (file:///home/<user>/.t3/runtime/versions/0.0.41-nightly.20260915.1752/t3:256742:34)
3	...
4	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:

text

1	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:

1	SSH_AUTH_SOCK=/home/<user>/.ssh/agent/s.SUIjO4iobl.sshd.U1DmzQ0mYB git pull
2	# git@github.com: Permission denied (publickey).
3	# 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

shell

1	# desktop.trace.ndjson
2	ssh.remoteServer.launch.start {"alias":"mbp24dev","runner":"archive","archiveVersion":"0.0.41-nightly.20260915.1752","stateKey":"9c2f9984ac7eff72"}
3	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"]}
4	ssh.environment.ensure.succeeded {"localPort":49753,"remotePort":3774,"remoteServerKind":"managed","issuedPairingToken":true}
5
6	# remote: managed server process
7	$ ps -o pid,ppid,lstart,args -p 2684763
8	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
9	$ tr '\0' '\n' < /proc/2684763/environ \| grep ^SSH_AUTH_SOCK=
10	SSH_AUTH_SOCK=/home/jh/.ssh/agent/s.SUIjO4iobl.sshd.U1DmzQ0mYB
11	$ ls -la /home/jh/.ssh/agent/
12	srw------- 1 jh jh 0 Sep 14 19:52 s.SUIjO4iobl.sshd.PGcZvniObu
13	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:

1	# ~/.zshenv
2	if [[ -S "/opt/orbstack-guest/run/host-ssh-agent.sock" ]]; then
3	export SSH_AUTH_SOCK="/opt/orbstack-guest/run/host-ssh-agent.sock"
4	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.

JJulius MarmingeSep 15, 2026

Thanks for the careful repro and for separating this from #10179. This looks like a real bug on the desktop-managed SSH launch path, not OrbStack-specific and not a duplicate of the systemd hole.

What we think is happening

Desktop SSH remotes with remoteServerKind: managed never touch t3code.service. launchOrReuseRemoteServer in packages/ssh/src/tunnel.ts runs a one-shot sh -l -s that writes ~/.t3/ssh-launch/<stateKey>/run-t3.sh and starts the server with:

1	nohup env T3CODE_NO_BROWSER=1 "$RUNNER_FILE" serve --host 127.0.0.1 --port "$REMOTE_PORT" --base-dir "$DEFAULT_SERVER_HOME" …

That process inherits the launch session’s SSH_AUTH_SOCK. With ForwardAgent yes, sshd creates a per-session socket (~/.ssh/agent/s.*.sshd.* or /tmp/ssh-XXXX/agent.N) and deletes it when that session ends. The managed server is already detached (reparented to PID 1, after #9843’s exec), so /proc/<pid>/environ keeps the dead path. Reconnect reuses a live PID without refreshing the env; a full relaunch only picks the next short-lived socket.

The long-lived -N -L tunnel is a different SSH session (ControlMaster=no, no -A). It does not own or republish an agent socket to the server.

Your /proc + ls + SSH_AUTH_SOCK=<dead> git pull vs a live socket pins this. It also matches why the systemd instance on 3773 with the #10179 drop-in stayed healthy: that process never inherited this launch-session socket.

Same family as #10179 (systemd missing SSH_AUTH_SOCK), #5740 (WSL), #3067 (devcontainer timing), and #971 (local macOS desktop). Not a duplicate — here the socket is present at exec and dies with the launcher. #10312’s login-shell backfill would not help: your probe on #10179 was absent, and this server already has a socket (the wrong one). Open #8190 already describes this lifetime bug and sketches a dedicated ssh -A keepalive plus $STATE_DIR/agent-sock; it is unvouched and review-blocked, so treat it as a design reference, not a merge candidate.

Workaround

The zshenv export of a durable socket (OrbStack host-ssh-agent.sock) plus a managed-server relaunch is the right workaround on hosts that have one. It will not cover a remote whose only agent is a forwarded per-session socket.

What we should change

Keep a long-lived owner of the forwarded agent for the life of the desktop connection (dedicated ssh -A, or attach forwarding to the existing tunnel and share that session), point t3 serve at a stable path under ~/.t3/ssh-launch/<stateKey>/, and re-resolve that path on reconnect — including when the managed PID is reused. Do not inherit the one-shot launch session’s SSH_AUTH_SOCK without that owner. A symlink with no live owner still goes stale when the launch session exits.

Secondary: GitVcsDriver.pullCurrentBranch / fetchRemoteForStatus replace git stderr with git pull failed / Background Git fetch exited with a non-zero status, so Permission denied (publickey) never reaches the UI.

#10951 (keep the managed server after desktop close) would make a stale socket last longer; that work should not land without an agent owner.

Keeping this open as an accepted bug on packages/ssh managed launch.

GPT 6 via Cursor Cloud (triage only; no code change).

TTinBane24d ago

@juliusmarminge your triage above lists a secondary problem: GitVcsDriver.pullCurrentBranch replaces Git's output with git pull failed, so Permission denied (publickey) never reaches the UI. #12485 fixed the fetch half of that. #18083 fixed the pull half the same way: the same helpers and fixed messages, one call site, and no raw Git output. It was closed as a diagnostics change rather than a bug fix. Would you take it as the pull counterpart to #12485? If so, I'll rebase it and ask for it to be reopened.

JJulius Marminge20d ago

Triage update: searched all 945 open issues; no duplicate of this desktop-managed socket-lifetime report found. The earlier implementation #8190 is now closed and unmerged. No fresh desktop reproduction was run. Routing to Julius: the fix changes SSH credential forwarding/socket ownership, which is outside the automated triage flow’s allowed scope. Leaving this accepted bug open; no replacement PR created.

JJulius Marminge20d ago

Reproduced on main 3b95e7831b using the real managed launcher and server with an isolated Linux SSH host and ForwardAgent yes. After the launching SSH session exited, the server retained a removed socket: ssh-add -l returned No such file or directory, and fetch/pull returned Permission denied (publickey). The same repository fetched and pulled successfully inside a live forwarded SSH session. Desktop UI on macOS was not exercised.