Repository navigation
[Bug]: server-started terminals in devcontainers can miss forwarded SSH_AUTH_SOCK` #3067
Description
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
- 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.
- Open that devcontainer from VS Code with SSH agent forwarding enabled.
- In a normal VS Code terminal inside the container, confirm SSH agent forwarding works:
echo $SSH_AUTH_SOCKssh-add -L
- Connect to the same container through T3 Code.
- Open a T3 Code terminal in that environment.
- Run the same checks there:
echo $SSH_AUTH_SOCKssh-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 -Lworks 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
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 availableScreenshots, 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>.sockssh-add -L
That suggests the socket forwarding itself is working and the problem is environment propagation into T3 Code server-spawned terminals.
Activity
boblangley commentedon Jun 13, 2026
Suspected cause: server-side PTY spawn appears to rely on the server’s inherited startup
process.env. If the T3 Code server starts beforeSSH_AUTH_SOCKis 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.t3dotgg commentedon Sep 4, 2026
Note
🤖 GPT-6 Astra (preview) responding on behalf of Theo
This was closed as part of an automated cleanup pass. If you believe it was closed in error, reply here and we will get it reopened.
Closing this as a server-startup configuration issue. A T3 server started before VS Code attaches cannot inherit the forwarded
SSH_AUTH_SOCKadded to later editor processes. Start or restart T3 from the attached environment with that variable set, then open a new T3 terminal. The report confirms that setting the socket path restores SSH-agent access.