Skip to content

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

Description

@jahands

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.

Activity

  1. added
    via-triageFiled through npx t3 triage
    bugSomething is broken or behaving incorrectly.
    acceptedfeature request accepted
    on Sep 5, 2026
  2. juliusmarminge commented on Sep 5, 2026

    @juliusmarminge
    Member

    Thanks for the careful repro. This looks like a real bug in the Linux systemd service environment, not an OrbStack or Git problem.

    What we think is happening

    t3code.service is generated by renderBootServiceUnit() in apps/server/src/cloud/bootService.ts. The unit only sets T3CODE_HOME and T3_BOOT_SERVICE_UNIT. It does not set SSH_AUTH_SOCK.

    Server startup (fixPath() in apps/server/src/os-jank.ts) backfills HOME and PATH from a login shell, but not SSH_AUTH_SOCK. The desktop app already does that backfill in apps/desktop/src/shell/DesktopShellEnvironment.ts (see #971 / #972). Git children inherit process.env (GitVcsDriverCore), so a service with no agent socket fails SSH git fetch.

    Worktree create with “start from origin” calls gitWorkflow.fetchRemote before createWorktree (apps/server/src/ws.ts). That matches the UI error:

    Git command failed in GitVcsDriver.fetchRemote (...): git fetch origin failed

    /proc/<pid>/environ is the exec-time environment, so it is a weak check for PATH (the server mutates process.env later). It is a fair check here: nothing in the service path writes SSH_AUTH_SOCK. Your env -u SSH_AUTH_SOCK vs explicit-socket comparison, and the drop-in restoring worktree create, pin the cause.

    Same family as #4913 (systemd PATH), #5740 (WSL SSH_AUTH_SOCK), #3067 (devcontainer forwarded agent), and #971 (macOS desktop). Not a duplicate — this surface is the Linux user unit inside OrbStack.

    Workaround

    The drop-in is the right workaround. t3 service update rewrites the unit file, not t3code.service.d/, so this should survive updates:

  3. jahands commented on Sep 5, 2026

    @jahands
    Author

    sorry for the ai slop 😭

  4. jahands commented on Sep 5, 2026

    @jahands
    Author

    Thanks for the careful repro

    From my clanker to yours, you're welcome @juliusmarminge 😂

  5. juliusmarminge commented on Sep 5, 2026

    @juliusmarminge
    Member

    I confirmed that current main cb9a6942 recovers PATH but not SSH_AUTH_SOCK in a controlled startup test. I haven't reproduced the full OrbStack setup yet.

    One check will tell us whether adding socket backfill to that existing probe covers your environment. From the working Orb terminal, if your login shell is Bash or Zsh, could you run:

    env -u SSH_AUTH_SOCK "$SHELL" -ilc 'test -n "${SSH_AUTH_SOCK:-}" && printf "present\n" || printf "absent\n"'

    Please share only present or absent and the shell name. For another shell, tell us its name instead. If it errors or hangs, report that rather than treating it as absent.

    This removes the variable only in a child shell. It does not change your service, run Git or SSH, or print credentials. present supports the small startup-backfill fix; absent means that alone won't recover OrbStack's agent. Keeping this open while we verify that distinction.

    GPT 6 Astra via Codex in T3 Code.

  6. jahands commented on Sep 6, 2026

    @jahands
    Author

    @juliusmarminge I ran the command in OrbStack login shell (which uses ZSH):

    🐧 MAC5DEV ~ ⌚4:39:30
    $ env -u SSH_AUTH_SOCK "$SHELL" -ilc 'test -n "${SSH_AUTH_SOCK:-}" && printf "present\n" || printf "absent\n"'
    absent
    
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    acceptedfeature request acceptedbugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions