[Bug]: OrbStack systemd service misses SSH_AUTH_SOCK, causing worktree creation to fail at git fetch

Context: I started using t3 connect inside OrbStack because it speeds up pnpm install by 10x, making worktrees much faster to start: https://x.com/jachands/status/2096299607894491166

The only thing I had issues with is git operations failing because the SSH_AUTH_SOCK env var isn't set in the service. I confirmed setting it fixed my issue, so for now I'm patching it after every update.

From the Clanker:

Before submitting

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

Related: #4913 (systemd service missing the user's PATH), #5740 (SSH_AUTH_SOCK missing in the WSL backend), #3067 (forwarded agents in devcontainers), and #971 (macOS desktop SSH-agent inheritance). This report concerns the Linux systemd user service inside OrbStack, failing to authenticate Git fetches through OrbStack's forwarded host agent.

Area

apps/server

Steps to reproduce

1. Run an Arch Linux ARM machine in OrbStack on macOS, with a working SSH identity available through OrbStack's forwarded host agent.

2. In the guest, use a repository whose origin is an SSH URL on GitHub. Confirm that git fetch --dry-run origin succeeds from a regular Orb shell. In this environment, the shell has:

   SSH_AUTH_SOCK=/opt/orbstack-guest/run/host-ssh-agent.sock
   

3. Run t3code using its t3code.service systemd user unit, without a custom SSH-agent environment override.

4. Open that guest-side repository in t3code and try to create a new worktree.

Expected behavior

Worktree creation can fetch the remote using the SSH agent already available inside the Orb, without a manual systemd override.

Actual behavior

Worktree creation fails with this UI message (repository path anonymized):

Git command failed in GitVcsDriver.fetchRemote (/home/<user>/src/<repo>): git fetch origin failed

The running t3code server's /proc/<pid>/environ had no SSH_AUTH_SOCK. The service unit also had no setting for it. A regular Orb shell had the working socket path above, and ssh-add -l successfully listed an identity.

Impact

Major degradation or frequent failure: creating a worktree fails for the affected SSH remote, although fetching from the shell works.

Version or commit

t3@0.0.39-nightly.20260905.1285

Environment

• macOS host running OrbStack
• Guest: Arch Linux ARM (rolling), aarch64
• Node.js 22.23.2
• t3code launched through a systemd user service and its service-launcher.mjs
• Repository stored in the guest's Linux filesystem, not the host-mounted directory
• GitHub SSH remote, authenticating through OrbStack's forwarded host SSH agent

Logs or stack traces

From the same repository in the guest, removing only the agent variable reproduces an authentication failure:

env -u SSH_AUTH_SOCK \
  GIT_SSH_COMMAND='ssh -o BatchMode=yes -o ConnectTimeout=10' \
  git fetch --dry-run origin

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Exit status: 128. Explicitly supplying the socket succeeds, with exit status 0:

SSH_AUTH_SOCK=/opt/orbstack-guest/run/host-ssh-agent.sock \
  GIT_SSH_COMMAND='ssh -o BatchMode=yes -o ConnectTimeout=10' \
  git fetch --dry-run origin

Workaround

Create ~/.config/systemd/user/t3code.service.d/orbstack-ssh-agent.conf containing:

[Service]
Environment=SSH_AUTH_SOCK=/opt/orbstack-guest/run/host-ssh-agent.sock

Then run:

systemctl --user daemon-reload
systemctl --user restart t3code.service

After restarting, the running server had the variable, a fetch using that server's process environment succeeded, and worktree creation in t3code worked again.

This is a separate drop-in, not an edit to the generated service unit. Whether an update removes the drop-in has not been tested.

Suggested fix

Resolve the available SSH-agent environment for the Linux service, including OrbStack's forwarded host agent, so Git subprocesses can use it. Account for agent sockets that can change across sessions rather than assuming every socket path is permanent.

Also surface the underlying Git stderr in this failure: Permission denied (publickey) would make the missing authentication context easier to diagnose than git fetch origin failed alone.

Start in apps/server and inspect service-launcher.mjs together with the generated t3code.service user unit. Reproduce the missing SSH_AUTH_SOCK with the provided systemd and git fetch commands, then verify the service can use the available agent when creating a worktree. Done means SSH-backed fetches work without a manual drop-in and the underlying Git stderr is visible in failures.