[Codex App] False-positive network security warnings during legitimate remote AI infrastructure validation

What version of the Codex App are you using?

26.803.81509 (build 6415)

What subscription do you have?

Authenticated desktop account; the subscription tier is not exposed to the agent.

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

During a long-running AI infrastructure task, Codex repeatedly surfaces network-security or safety warnings for a legitimate remote model-serving validation workflow.

The local Mac is only used to issue SSH orchestration commands and read logs. Model serving and request generation run inside the remote server/container, and the load generator connects to the model API over 127.0.0.1 on that remote server. No bulk model requests are sent from the local Mac, and the workflow does not scan networks or contact unrelated hosts.

This is a normal AI Infra workflow: launch vllm serve, run server-local vllm bench or bounded HTTP probes, inspect failures, restart an owned process group, and repeat. The repeated warnings interrupt autonomous debugging and make safe server-side validation unnecessarily difficult.

The exact warning text was not retained in terminal logs. A private session identifier can be provided to OpenAI Support if needed.

Steps to reproduce

1. Open a repository task in the Codex desktop app on macOS.
2. Ask Codex to validate a remote model-serving stack over SSH.
3. Launch a model server inside a remote container.
4. From inside that same container, run vllm bench or bounded HTTP requests against 127.0.0.1.
5. Use the local Codex task only for SSH control, health checks, and log collection.
6. Continue a long diagnosis with repeated server restarts and server-local concurrency sweeps.
7. Observe recurring network-security or safety warnings even though the traffic source and destination are both server-local.

Expected behavior

Codex should distinguish server-local workload traffic executed behind SSH from local network scanning or abusive outbound traffic. Legitimate, user-authorized AI infrastructure validation should proceed without repeated false positives.

If a warning is necessary, it should identify the triggering command or rule, include a request/correlation ID, and avoid warning repeatedly after the user has clarified that all workload traffic is server-local.

Additional information

• The workflow deliberately moved all bulk request generation to the server to minimize local network-security risk.
• Remote targets, addresses, node identifiers, model paths, and credentials are intentionally omitted from this public report.
• Impact: repeated interruptions, reduced autonomy for long-running infrastructure debugging, and pressure to avoid otherwise standard benchmarking tools.

The report names no source file or test and does not retain the warning text. Start by reproducing the SSH-controlled remote-container workflow with vllm serve and server-local vllm bench or 127.0.0.1 probes, then capture the triggering rule or correlation ID. Done means legitimate server-local validation no longer produces repeated false positives while unrelated network activity remains warned.