[Bug]: server-started terminals in devcontainers can miss forwarded SSH_AUTH_SOCK`

[boblangley]

Before submitting

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

Area

apps/server

Steps to reproduce

1. Run T3 Code server inside a devcontainer in a way that starts the server at container boot, before VS Code attaches.
   • In my case this is done with a devcontainer feature/entrypoint, but the important condition is only that the server process starts before the editor session injects its forwarded env.
2. Open that devcontainer from VS Code with SSH agent forwarding enabled.
3. In a normal VS Code terminal inside the container, confirm SSH agent forwarding works:
   • echo $SSH_AUTH_SOCK
   • ssh-add -L
4. Connect to the same container through T3 Code.
5. Open a T3 Code terminal in that environment.
6. Run the same checks there:
   • echo $SSH_AUTH_SOCK
   • ssh-add -L

Expected behavior

If the container has a forwarded SSH agent available, T3 Code terminals in that same container should be able to use it too.

At minimum, T3 Code terminal behavior should match a normal VS Code terminal in the same attached devcontainer.

Actual behavior

A normal VS Code terminal in the container has working SSH agent access, but a T3 Code terminal in that same container does not.

In my repro:

• the forwarded socket exists inside the container
• ssh-add -L works in a plain VS Code terminal
• the T3 Code server process did not inherit SSH_AUTH_SOCK
• T3 Code terminal sessions spawned from that server miss the forwarded SSH agent and fail for Git-over-SSH / SSH-agent-backed workflows

I know this is a slightly special setup because I am starting the T3 Code server as part of devcontainer startup, but I think it still falls under a general class of bugs where the server process starts before later environment injection happens. The key point is that sibling VS Code terminals in the same container can use the forwarded agent while T3 Code terminals cannot.

Impact

Major degradation or frequent failure

Version or commit

1e87640

Environment

Linux devcontainer opened from VS Code remote containers. T3 Code server runs inside the container and starts before VS Code attaches. VS Code injects a forwarded SSH agent socket into attached processes (for example /tmp/vscode-ssh-auth-<id>.sock).

Logs or stack traces

# In a plain VS Code terminal inside the container:
echo "$SSH_AUTH_SOCK"
/tmp/vscode-ssh-auth-<id>.sock

ssh-add -L
# succeeds and lists keys

# In the running T3 Code server process environment:
# SSH_AUTH_SOCK is missing

# In a T3 Code terminal in the same container:
echo "$SSH_AUTH_SOCK"
# empty or unusable

ssh-add -L
# fails because no agent is available

Screenshots, recordings, or supporting files

No response

Workaround

If I manually export the VS Code forwarded socket path inside the container, SSH agent access works.

Example:

• export SSH_AUTH_SOCK=/tmp/vscode-ssh-auth-<id>.sock
• ssh-add -L

That suggests the socket forwarding itself is working and the problem is environment propagation into T3 Code server-spawned terminals.

[boblangley]

Suspected cause: server-side PTY spawn appears to rely on the server’s inherited startup process.env. If the T3 Code server starts before SSH_AUTH_SOCK is present, later terminal sessions inherit that stale environment. This seems related in shape to prior shell-env hydration fixes, but on the server-side terminal path rather than desktop startup.