Sign up
View stargazers13Sign up

[Bug]: Windows/WSL commit actions fail for SSH-signed commits because SSH_AUTH_SOCK is not inherited#5740

openedAug 8, 2026byDdjordje-st

Before submitting

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

Related but distinct reports: #274 covers passphrase-protected GPG signing, #971 covers a missing SSH_AUTH_SOCK in the macOS desktop app, and #3067 covers forwarded agents in devcontainers. This report is for the Windows desktop app using the WSL backend with SSH commit signing.

Area

apps/desktop

Steps to reproduce

  1. On Windows, configure T3 Code to use a repository and worktree inside WSL.

  2. Configure Git in WSL to sign commits with an SSH key:

    shell
    1git config --global commit.gpgsign true
    2git config --global gpg.format ssh
    3git config --global user.signingkey "<public SSH key>"

  3. Make the SSH agent available from the normal WSL login shell. Confirm that this succeeds:

    shell
    1test -S "$SSH_AUTH_SOCK"
    2ssh-add -l

  4. Open the repository in the T3 Code Windows desktop app and make changes in a T3-managed WSL worktree.

  5. Use any UI action that begins with a commit: Commit, Commit & push, or Commit, push & PR.

Expected behavior

T3 Code should inherit or resolve the WSL login shell's SSH agent environment so Git can create an SSH-signed commit.

If the signing agent is unavailable, the UI should surface Git's actionable stderr and identify commit signing as the failure instead of only reporting a non-zero exit status.

Actual behavior

Every UI action fails at the commit step. Files are staged, but no commit is created.

The toast only shows:

text
1Action failed
2
3Git command failed in
4GitVcsDriver.commit.commit
5(/home/<user>/.t3/worktrees/<repo>/<worktree>):
6Git command exited with a non-zero status.

The environment differs between the T3 backend and a normal login shell:

text
1T3 backend environment:
2SSH_AUTH_SOCK=unset
3ssh-add -l -> Could not open a connection to your authentication agent.
4
5bash -lic login-shell environment:
6SSH_AUTH_SOCK points to a valid socket
7ssh-add -l -> succeeds and lists the available identities

The repository configuration at the time of failure is:

text
1commit.gpgsign=true
2gpg.format=ssh
3user.signingkey=<public SSH key>

This strongly indicates that the Windows/WSL backend is not hydrating the login-shell SSH_AUTH_SOCK before it invokes git commit.

Impact

Major degradation or frequent failure

All three UI workflows are blocked for repositories where SSH commit signing is required.

Version or commit

T3 Code Nightly 0.0.33-nightly.20260808.1035

Environment

  • Windows desktop app
  • Windows NT 10.0.26200.0
  • WSL2, Ubuntu 24.04.4 LTS
  • Linux kernel 6.6.87.2-microsoft-standard-WSL2
  • Git 2.43.0
  • Repository and T3-managed worktree stored in the WSL filesystem
  • Provider: Codex app-server

Logs or stack traces

shell
1GitCommandError: Git command failed in GitVcsDriver.commit.commit
2(/home/<user>/.t3/worktrees/<repo>/<worktree>):
3Git command exited with a non-zero status.
4
5at commit (.../apps/server/dist/bin.mjs:34267:74)
6at runCommitStep (.../apps/server/dist/bin.mjs:43913:112)
7at runStackedAction.runAction (.../apps/server/dist/bin.mjs:43944:5)
8at runStackedAction (.../apps/server/dist/bin.mjs:44072:132)

The server trace and toast omit the underlying Git stderr, which makes the signing failure invisible.

Screenshots, recordings, or supporting files

The failure toast shows the same generic GitVcsDriver.commit.commit non-zero-status error quoted above when clicking the "Commit" button.

Image

Workaround

Commit manually from a normal WSL login shell where SSH_AUTH_SOCK is populated, then use the remaining push/PR actions.

If unsigned commits are acceptable for the repository, a temporary alternative is:

shell
1git -c commit.gpgsign=false commit ...

This should not require changing the user's global Git configuration.

Jjcardama-xseedAug 12, 2026
Synced from GitHub

Ran into this one too. Fix is on a branch: https://github.com/jcardama/t3code/tree/fix/5740/wsl-ssh-auth-sock-inheritance

The cause is that the WSL backend starts through wsl.exe --exec, which skips the login shell, so nothing ever sets SSH_AUTH_SOCK and git can't reach the agent. Forwarding it from Windows via WSLENV doesn't help either, the socket path only exists inside the distro.

The preflight already runs bash -l -s and pulls node and PATH out of it, so I added the socket to that same probe and pass it through to env at launch. Nothing gets emitted if the socket is missing or dead, so it's a no-op for anyone not signing commits.

The ${SSH_AUTH_SOCK:-} default is load bearing. Without it a login profile with set -u kills the probe before node-pty runs and the backend won't start at all, including for people who don't sign anything.

Couldn't open a PR, it comes back with "must be a collaborator". Branch is there if it's any use.

JJulius Marminge4d ago

Checked current main at ed9b7ca9c5. Existing open PR #10312 explicitly targets this report with server login-shell SSH_AUTH_SOCK recovery; no competing PR opened. Its verification does not cover Windows/WSL. This triage environment is Linux without wsl.exe, so the Windows desktop → WSL launch sequence could not be run. The current server startup probe still reads PATH, __MISE_DIFF and JAVA_HOME without SSH_AUTH_SOCK. Credential-environment propagation requires maintainer review; leaving this issue open.

JJulius Marminge4d ago

Rechecked current main 3b95e7831b on Linux. A direct production-startup check with a temporary SSH agent and disposable signing key reproduces the missing socket: Git exits 128 with Couldn’t get agent socket?. Existing fix #10312 recovers the socket and creates an SSH-signed commit under identical conditions. Its focused startup/shell tests pass: 63 passed, 1 skipped. Added bugfix to that PR; no competing PR opened.

The Windows desktop → WSL sequence remains unverified: wsl.exe is unavailable on this VM. The PR includes the runtime script and both transcripts. Leaving this issue open pending the fix.

Lloeiks1d ago
Synced from GitHub

I'm having the same issue, I load my SSH keys using KeePassXC and so on agent cannot commit due to same issue, I do the same on macOS as well but macOS+KeePassXC doesn't have any issues until now (was using T3 Code Nightly in both devices same versions). I don't know how @djordje-st loads his SSH key and that might be the only difference between us, I load it via KP as I said.

I do have problems when agent needs to commit other than committing (or in other words when signing needed) I don't have any issues, so I commit manually for now.

I believe cause of my problem is exactly same but only different setup probably.