Network safety mechanism is absurdly trigger-happy and repeatedly blocks legitimate local coding work

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

26.5818.61809

What subscription do you have?

ChatGPT Plus

What platform is your computer?

No response

What issue are you seeing?

The network-security mechanism is producing ridiculous false positives during completely legitimate, authorized, local software engineering work.

In my case, Codex was working on a LOCAL QEMU testing task. The task involved building a minimal guest, reproducing CPU exception behavior, and distinguishing cases such as #GP and #PF. There was no external target, no network scanning, no credential access, no exploitation of third-party systems, and no persistence.

Codex itself correctly understood this context. It explicitly acknowledged that the task was local and legitimate and even said that the previous block was a false positive.

Then the system blocked the task AGAIN with:

We are unable to complete this request.
Some cybersecurity requests require additional safeguards. Please visit Trusted Access to verify your identity and enable access.

This is absurd.

The model understands the task. The task is plainly local. The conversation explicitly establishes the authorization boundary. Yet some other safety layer apparently sees a few words associated with low-level systems or vulnerability research and slams the brakes anyway.

At this point the mechanism behaves less like a security system and more like a broken keyword filter.

It is extremely disruptive for anyone doing serious compiler, VM, static-analysis, fuzzing, systems, or software-quality research.

The most frustrating part is that explaining the authorization and local scope does not reliably help. The model can literally say:

this is indeed a false positive

and the product can still immediately block the continuation.

That is a terrible user experience and a terrible safety-system design.

What steps can reproduce the bug?

A representative reproduction is:

1. Start a normal local coding task involving QEMU/system emulation.

2. Explicitly establish the scope, for example:

   • all code and test data are local;
   • no external systems are targeted;
   • no network scanning is performed;
   • the task is software-quality/debugging research.

3. Ask Codex to build or minimize a small local guest/test case that reproduces CPU exception behavior.

   In my case, the task involved ordinary low-level concepts such as:

   • BIOS boot;
   • long mode;
   • IDT setup;
   • serial/debug output;
   • a replaceable test payload;
   • distinguishing exceptions such as #GP and #PF.

4. Codex starts performing the task normally and edits local source files.

5. The safety mechanism interrupts the task.

6. Tell Codex that this is a false positive and reiterate that the task is completely local.

7. Codex acknowledges that the block is a false positive and correctly summarizes the safe scope.

8. Continue the same task.

9. The product blocks it AGAIN with the generic network-security / Trusted Access message.

There is no meaningful security-boundary change between steps 7 and 9.

No external target was introduced.
No networking was introduced.
No unauthorized access was introduced.
No harmful action was introduced.

The only thing that changed was that the coding task continued.

That makes this look strongly like context-insensitive classification rather than meaningful risk evaluation.

What is the expected behavior?

Codex should be capable of distinguishing:

• local software debugging,
• local QEMU/VM testing,
• compiler and runtime testing,
• static-analysis research,
• fuzzing of software under the user's control,
• crash minimization,
• exception handling tests,
• vulnerability-related software-quality research,

from actual unauthorized cyber activity.

Once the conversation clearly establishes that the environment is local and authorized, that context should survive across subsequent turns.

The system should NOT repeatedly forget the authorization boundary and reclassify ordinary local engineering work as suspicious just because words such as "guest", "exception", "payload", "fuzzing", "vulnerability", "#PF", or "#GP" appear.

And if the system does block something, it should identify the actual operation it considers unsafe instead of dumping a useless generic cybersecurity warning.

A coding agent that cannot reliably distinguish a local QEMU exception reproducer from unauthorized network activity has a fundamentally broken safety boundary for systems programming work.

Additional information

This is not an isolated annoyance. Repeated false positives make Codex unreliable for legitimate low-level engineering and software-security research.

The current behavior is:

• context-blind;
• excessively trigger-happy;
• inconsistent;
• opaque;
• hostile to legitimate developer workflows.

Frankly, the current design is ridiculous.

A safety mechanism should evaluate what the user is actually doing, not panic whenever technically loaded vocabulary appears.

If the model already understands that:

1. the environment is local,
2. the user controls the software,
3. there is no external target,
4. there is no network interaction,
5. the requested operation is ordinary debugging/testing,

then overriding that understanding with another generic cyber block accomplishes nothing except destroying the workflow.

Even worse, in this case Codex itself explicitly recognized the previous interruption as a false positive, adjusted its approach, and was still blocked again.

That is almost a perfect demonstration that the current mechanism is broken.

If this behavior is intentional, then the policy boundary is badly designed for a coding product.

If it is unintentional, then this is a serious false-positive bug.

Either way, telling legitimate developers to keep rephrasing the same harmless local task or go through an unrelated "Trusted Access" flow is not a reasonable solution.

Please fix the classifier/context propagation instead of making users fight the safety system every few turns.

A safety system that generates this many obvious false positives is not "safer". It is just broken and disruptive.

Start by reproducing the reported local QEMU task and the repeated network-security block, using the steps and scope described in the issue. Trace where the safety decision and Trusted Access message are produced; done means authorized local work remains unblocked across turns and blocked responses identify the relevant operation instead of showing only the generic warning.