Windows Codex App command runner blocks Tailnet SSH/TCP from sandbox user after update

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

Version 26.616.32156 • Released Jun 18, 2026

What subscription do you have?

X20 Pro

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

After a Codex App update, shell/tool commands executed by Codex can no longer connect to a private Tailnet SSH host, even though the same SSH command works from normal Administrator PowerShell on the same machine.

This appears to fail before SSH authentication/key selection. The Codex command runner executes under a sandbox/offline Windows account rather than my normal Windows user. From inside the Codex runner:

• the Tailnet host resolves correctly
• ping to the Tailnet host succeeds
• TCP/22 fails
• ssh -vvv fails at socket connect with Windows socket error 10013 Permission denied

Normal PowerShell as my regular user can SSH to the same target successfully.

I also tried Windows Firewall outbound allow rules for:

• TCP/22 to the Tailnet range
• Windows OpenSSH
• the Codex app binary

Those rules did not change the behavior.

What steps can reproduce the bug?

In Codex App, run:
whoami
It shows a Codex sandbox/offline runner account rather than my normal Windows user.

In Codex App, run:
Test-NetConnection <tailnet-ip> -Port 22 -InformationLevel Detailed
Result:
PingSucceeded: True
TcpTestSucceeded: False

In Codex App, run:
C:\Windows\System32\OpenSSH\ssh.exe -vvv -o BatchMode=yes -o ConnectTimeout=5 <user>@<tailnet-host> "whoami"

Connecting to <tailnet-host> [<tailnet-ip>] port 22
finish_connect - ERROR: async io completed with error: 10013
connect to address <tailnet-ip> port 22: Permission denied
ssh: connect to host <tailnet-host> port 22: Permission denied

This looks related to the recent cluster of Windows sandbox issues after the update, including sandbox helper / CodexSandboxUser / ShellExecuteExW 1223 reports.

My visible downstream symptom is network access: the sandbox runner can resolve and ping the Tailnet host, but TCP is denied before SSH authentication.

What is the expected behavior?

Codex App command runner should be able to connect to the same approved local/private SSH targets that are reachable from the user’s normal PowerShell session, or provide a documented permission/reset path for allowing private-network/Tailnet access from the Windows sandbox runner.

At minimum, if network isolation is intentional, Codex should surface a clear permission/error message instead of failing as a low-level Windows socket 10013 Permission denied.

Additional information

I searched existing issues and this appears related to the current Windows sandbox regression cluster, but I opened this separately because the visible failure is network/Tailnet access rather than an edit/apply_patch failure.

I also commented on a related Windows sandbox helper issue and can link this issue there once submitted.

Sanitized diagnostics:

• Normal PowerShell as my user can SSH to the private host.
• Codex App command runner executes as a sandbox/offline runner account.
• Tailnet/private DNS resolution works.
• ICMP/ping works.
• TCP/22 fails before SSH authentication.
• Windows Firewall allow rules for TCP/22 to the Tailnet range, OpenSSH, and the Codex app binary did not resolve it.

Happy to test a supported reset/rebuild command if there is a safe way to clear or regenerate the Windows sandbox/firewall/proxy state.