What version of the Codex App are you using (From "About Codex" dialog)?

26.506.31421 (2620)

Bundled/local CLI observed:

codex-cli 0.130.0

What subscription do you have?

TODO: fill in subscription

What platform is your computer?

Local client:

Darwin 25.4.0 arm64 arm
macOS 26.4.1
OpenSSH_10.2p1, LibreSSL 3.3.6
docker buildx v0.33.0

Remote host:

TODO: fill in remote OS / uname -mprs

What issue are you seeing?

Codex App's Remote SSH feature appears to discover hosts from ~/.ssh/config, but the actual remote connection does not behave like normal OpenSSH for agent forwarding.

My normal terminal SSH connection honors this host's ForwardAgent yes configuration. When I connect manually with the same SSH host alias, the remote shell gets a usable forwarded SSH agent socket and private Git SSH access works.

Inside a Codex App Remote SSH project on the same host, the remote environment either does not have a usable forwarded agent or has an invalid/stale SSH_AUTH_SOCK. This breaks Docker BuildKit / buildx workflows that depend on SSH agent forwarding, for example builds using:

docker buildx build --ssh default ...

The failure happens before the useful build step because BuildKit is handed an unusable SSH agent socket. In one run, the start command failed before building because SSH_AUTH_SOCK pointed at a deleted socket.

This looks like Codex Remote SSH is not fully honoring the selected host's OpenSSH config, specifically ForwardAgent yes, or is preserving/exporting a stale SSH_AUTH_SOCK into the remote app-server/session environment.

What steps can reproduce the bug?

1. Configure an SSH host alias in ~/.ssh/config with agent forwarding enabled:

   Host my-devbox
     HostName <remote-host>
     User <user>
     ForwardAgent yes

2. Confirm normal terminal SSH honors the config:

   ssh my-devbox 'echo "SSH_AUTH_SOCK=$SSH_AUTH_SOCK"; test -S "$SSH_AUTH_SOCK" && echo socket-exists; ssh-add -l'

   Expected control result: SSH_AUTH_SOCK points at a live remote forwarded-agent socket, and ssh-add -l can list the local agent identities.

3. Open Codex App.

4. Use the Remote SSH feature to connect to the same my-devbox host alias and open a remote project.

5. In the Codex remote shell/tool environment, run:

   echo "SSH_AUTH_SOCK=$SSH_AUTH_SOCK"
   test -S "$SSH_AUTH_SOCK" && echo socket-exists || echo socket-missing
   ssh-add -l

   Actual result: SSH_AUTH_SOCK is missing, points to a deleted/nonexistent socket, or ssh-add -l cannot see the forwarded identities.

6. Try a BuildKit/buildx build that needs SSH during the build, for example a Dockerfile using a private Git dependency and:

   docker buildx build --ssh default="$SSH_AUTH_SOCK" .

   Actual result: the build fails because the SSH agent socket is not usable from the Codex remote session.

What is the expected behavior?

Codex App Remote SSH should honor OpenSSH config behavior for the selected host alias, including ForwardAgent yes, the same way a normal terminal ssh my-devbox invocation does.

At minimum:

• if ForwardAgent yes is configured and a local agent is available, the Codex remote session should get a live forwarded SSH_AUTH_SOCK;
• ssh-add -l in the Codex remote session should behave like ssh my-devbox 'ssh-add -l';
• Docker BuildKit/buildx SSH mounts should work with docker buildx build --ssh default ...;
• if agent forwarding is unsupported or unavailable, Codex should not export a stale/deleted SSH_AUTH_SOCK; it should leave it unset or show a clear diagnostic.

Additional information

Related issues that seem adjacent but do not cover this exact failure:

• #18301: Codex App Remote SSH uses id_rsa by default even if it doesn't exist. This suggests Remote SSH identity/config behavior differs from normal OpenSSH.
• #18322: Codex Remote SSH fails if RemoteCommand is included in SSH config. This is another SSH config parity issue.
• #18819: SSH connect timeout configurable; asks Codex Desktop to respect ~/.ssh/config where possible or expose equivalent settings.
• #20128: Codex App Remote SSH behaves differently from normal ssh <alias>/VS Code Remote SSH in a remote setup.

The issue is not that Codex fails to discover ~/.ssh/config hosts entirely. The host is visible/usable in Codex Remote SSH. The problem is that the connection/session does not appear to preserve the full OpenSSH behavior needed for agent forwarding.