Repeated Opaque Security Blocks Make Codex Unreliable for Unattended Engineering Work

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

26.901.51231

What subscription do you have?

Pro 20x

What platform is your computer?

windows 11

What issue are you seeing?

Codex repeatedly interrupts an explicitly authorized and tightly scoped development-environment test with a generic network-security error:
“Some network security requests require additional protection. Visit a trusted domain to verify your identity and enable access.”

This message is nearly useless. It does not identify:

• Which command or network destination was blocked
• Which policy or security rule was triggered
• Whether the block came from the sandbox, auto-review, the organization, or account verification
• What permission is missing
• Whether the operation can be retried
• What the user must actually do to resolve it

What steps can reproduce the bug?

Start a long-running Codex task in a local project.
Explicitly authorize a narrowly scoped development environment, host, namespace, object, and permitted operations.
Configure a scheduled task to return to the same conversation and continue the work.
Allow Codex to perform local validation followed by the approved remote operation.
At an unpredictable point, Codex blocks the network action with the generic security message and interrupts the workflow.

What is the expected behavior?

Codex should:

• Show the exact rejected action and destination.
• Explain which policy caused the rejection.
• Provide a concrete resolution path.
• Preserve the execution checkpoint.
• Resume automatically once the issue is resolved.
• Avoid asking for approval that the user has already explicitly provided.
• Distinguish a controlled development test from an unknown or genuinely dangerous target.

Additional information

Actual behavior
Codex abruptly stops the task, gives no actionable diagnostic information, and leaves the user unable to determine whether the task is paused, failed, partially executed, or safe to resume.
Scheduled execution does not solve the problem. A later run remains subject to the same unexplained block, so the product can repeatedly wake up, hit the same wall, and accomplish nothing.
Impact
This is not a minor usability issue. It makes Codex fundamentally unreliable for serious long-running engineering, debugging, testing, and incident-analysis workflows.
Hours of work can be wasted because the security layer behaves like a blind kill switch instead of a transparent risk-control system. An “agentic” product that unpredictably sabotages its own approved workflow, provides no useful explanation, and cannot reliably resume is not suitable for unattended operation.
I am not requesting a security bypass. I am requesting a security system that is transparent, deterministic, and professionally implemented.
Please fix this broken behavior instead of forcing users to repeatedly fight an opaque policy wall with no diagnosis and no meaningful recovery path.

No files, tests, or entry points are named. Start by reproducing the long-running scheduled task and capture where the generic security block interrupts the approved network operation. Done means identifying the rejected action and policy, providing a concrete recovery path, preserving the checkpoint, and resuming safely after resolution.