Windows App Server sandbox cannot reach the existing OpenSSH agent named pipe

Summary

On native Windows, a model-free app-server command/exec command running under the default workspace-write sandbox cannot reach the existing Windows OpenSSH agent named pipe, even though the same public-identity preflight succeeds from a normal PowerShell process.

This prevents repositories with required SSH commit signing from creating signed commits through the sandbox. Unsigned nested Git operations and ordinary filesystem writes succeed, so this is an endpoint-connectivity problem rather than a filesystem-root problem.

Environment

• Windows 11
• Codex Desktop package: 26.721.4979.0
• bundled CLI / App Server: codex-cli 0.146.0-alpha.3.1
• Windows sandbox backend: unelevated
• sandbox policy: default workspace-write
• Git signing: gpg.format=ssh, commit.gpgsign=true
• signing program: Windows OpenSSH ssh-keygen.exe
• expected endpoint: \\.\pipe\openssh-ssh-agent

Reproduction

1. Start the Windows ssh-agent service and load an SSH signing identity.
2. Confirm a normal PowerShell process can run the native Windows ssh-add.exe -L against the default named pipe.
3. Start codex app-server from a disposable native-Windows project directory.
4. Run the same bounded, read-only identity preflight with command/exec under the default workspace-write policy.
5. Repeat with an env overlay containing only SSH_AUTH_SOCK=\\.\pipe\openssh-ssh-agent.

Observed

• Host PowerShell preflight: succeeds.
• App Server sandbox with implicit default endpoint: endpoint unreachable.
• App Server sandbox with explicit exact SSH_AUTH_SOCK overlay: endpoint unreachable.
• The public identity-set hash observed on the host is stable; no private key material is copied or read.
• The repository signing config is unchanged.

Expected

A sandboxed process that is allowed to execute the native OpenSSH client should be able to connect to the current user's already-running OpenSSH agent endpoint for a signing operation, or App Server should expose a narrowly scoped supported mechanism for this dependency endpoint.

Security boundary

This report does not request broader filesystem roots, disabling commit signing, copying private keys, starting a substitute agent, or bypassing the sandbox. The desired behavior is access to the already-existing user-owned agent endpoint only.

Related but not duplicate

#8343 concerns creating a new IPC pipe from within the sandbox. This report concerns connecting to the pre-existing Windows OpenSSH agent named pipe from an App Server sandboxed child.