Codex Remote blocks private-LAN SSH with no per-conversation approval path

Summary

Codex Remote/Desktop cannot SSH to a host on the user's private LAN, and there is no usable way for the user to grant scoped, per-conversation authorization.

Reproduction

1. From a Codex task on macOS, run an SSH command to a NAS on the private RFC1918 LAN:

``console
ssh -i ~/.ssh/<key> codex@192.168.x.x
``

1. The connection fails before reaching the SSH server:

``text
ssh: connect to host 192.168.x.x port 22: Operation not permitted
``

1. Retry through the command tool's scoped escalation mechanism.
2. The escalation is rejected automatically because the active approval policy has sandbox_approval: false. No approval dialog is shown to the user.

Expected behaviour

When an otherwise sandboxed command needs to connect to a private-LAN SSH endpoint, Codex should offer a narrowly scoped approval prompt, ideally valid only for the current conversation/task and the specified executable/host/port.

The user explicitly does not want permanent blanket network access. They want to authorize SSH once per conversation.

Actual behaviour

The SSH socket is blocked and the mechanism intended to request permission is itself disabled. The user cannot authorize the operation even while present. A browser-based local web console may still be reachable, but that is not an equivalent or reliable way to administer the host OS.

Impact

This makes Codex Remote unusable for common self-hosted/NAS administration workflows that require direct SSH. It also encourages awkward browser-console workarounds rather than a clear, auditable, least-privilege approval.

Suggested direction

Provide one of:

• a per-conversation approval dialog for private-LAN network connections;
• a narrowly scoped allow rule such as executable + destination host + destination port;
• clear product UI explaining why approval cannot be requested and how the user can enable it.

No credentials, private keys, or public keys are included in this report.