Repeated false-positive cybersecurity safety checks can escalate into near-every-turn checks across ChatGPT and Codex

What issue are you seeing?

Summary

I am experiencing persistent false-positive cybersecurity / additional safety checks across both ChatGPT and Codex.

The problem appears to have started after an earlier benign Codex task was incorrectly classified as cybersecurity-related. I then discussed that false positive in ChatGPT/Astra and pasted the previously blocked task to ask what wording might have triggered the classifier.

Shortly afterward, additional cybersecurity checks began appearing on a very large proportion of subsequent messages, including completely benign prompts and when using GPT-5.6 Sol.

I cannot prove that discussing the original false positive caused the later account-wide behavior, but the timing is notable and raises concern about a possible self-reinforcing safety-classification loop.

The issue materially interfered with normal use of ChatGPT, Codex, Work, and Astra Pro.

---

Initial false positive

The first incident occurred in Codex with GPT-5.6 Sol.

The task concerned an internal diagnostics module in my own project.

It was ordinary local software-engineering work and did not involve:

• external systems;
• network access;
• exploitation;
• credentials;
• malware;
• unauthorized access;
• persistence or evasion;
• offensive security activity.

The task wording had been prepared by ChatGPT itself.

Nevertheless, it triggered a cybersecurity / additional safety check and was stopped.

---

What happened afterward

After that incident, I opened a normal ChatGPT conversation using Astra.

My purpose was simply to understand the false positive.

I pasted the previously blocked task and asked the model what specific wording could have caused the cybersecurity classifier to react to an otherwise benign local-development task.

After this discussion, I began seeing additional cybersecurity checks on a very large proportion of subsequent prompts.

These checks were no longer limited to Astra or to cybersecurity-adjacent topics.

They also occurred:

• with GPT-5.6 Sol;
• in unrelated conversations;
• on ordinary non-security work;
• on prompts with no meaningful connection to networking or cybersecurity.

I am not claiming proven causation between the Astra discussion and the later checks, because only OpenAI has the telemetry necessary to establish that.

However, the transition from isolated false positives to near-every-turn checks occurred immediately after I used ChatGPT to analyze and quote the earlier false-positive task.

This raises a possible feedback-loop concern:

a user may receive a false-positive cybersecurity classification, then discuss or quote that false positive in order to understand it, and that discussion may itself produce enough cybersecurity-like context to cause more aggressive subsequent safety monitoring.

If account-level or cross-conversation safety state is involved, this can turn one false positive into a persistent usability problem.

---

Second Codex incident

A separate later incident occurred during completely benign architecture work in the same project.

The task was to establish ownership boundaries between two internal modules.

Again, there was no external target, network activity, exploitation, credential access, or offensive-security objective.

The task formulation was generated by ChatGPT/Work itself.

The task then triggered the cybersecurity safety mechanism repeatedly — approximately three times during attempts to proceed.

Afterward, the model itself explained that its own wording had included terms or concepts such as:

• "attack";
• "forgery";
• substitution of internal states;
• "introspection".

Those terms were introduced as part of an architectural description of module ownership and invalid internal-state behavior.

In other words:

1. ChatGPT generated a benign software-engineering task.
2. ChatGPT chose security-adjacent terminology to describe it.
3. A downstream safety mechanism appears to have interpreted that terminology as cybersecurity activity.
4. The resulting task was repeatedly interrupted.

This suggests that the generating model and the downstream cybersecurity classifier may not be sufficiently aligned on contextual interpretation.

A benign local architecture problem should not become a cybersecurity request merely because the model itself chose words such as "attack", "forgery", or "introspection".

---

Astra Pro: safety check can destroy the original turn

There is an additional problem when this occurs during Astra Pro usage.

When an Astra Pro research/reasoning task triggers an additional cybersecurity check, the original turn does not always resume correctly afterward.

Instead, I have encountered the following sequence:

1. Start a normal Astra Pro task.
2. Additional cybersecurity safety check appears.
3. The check completes.
4. The original reasoning does not resume.
5. The UI shows "Reasoning stopped".
6. I must send another user message to make the model continue or reconstruct the interrupted task.

This is significantly worse than a delay.

It means a false-positive safety check can effectively destroy an otherwise valid Astra Pro run.

Because Astra Pro usage is limited, requiring another turn to recover from a safety interruption also creates a potential usage/quota impact.

I cannot determine from the client whether the failed/interrupted run and the recovery turn are metered separately, so I am not claiming a specific billing or quota bug.

The observable problem is simply that a safety check can require an additional Astra Pro invocation because the original turn fails to resume.

---

Practical impact

At its worst, the issue was not an occasional false positive.

It made normal work unreliable.

Observed impact included:

• repeated multi-minute additional safety checks;
• checks on clearly benign prompts;
• checks occurring with GPT-5.6 Sol as well as Astra;
• repeated checks within the same benign task;
• interruptions before useful repository work begins;
• inability to predict which ordinary engineering terminology will trigger the classifier;
• apparent persistence across unrelated conversations;
• Astra Pro turns ending with "Reasoning stopped" instead of resuming;
• needing additional user turns to recover interrupted work.

This materially degraded the usability of both ChatGPT and Codex for normal software-engineering and research workflows.

---

Behavior may be temporary / decay over time

The behavior also appears to be intermittent and may decay over time.

After a period in which additional cybersecurity checks occurred on a very large proportion of benign turns, the frequency later decreased without any deliberate action or configuration change on my side.

This makes the issue harder to reproduce deterministically and suggests that the behavior may not be tied only to the content of an individual prompt.

I cannot determine whether this reflects an account-level temporary state, classifier state, backend changes, or something else.

---

Expected behavior

Cybersecurity safeguards should primarily evaluate:

• the actual requested capability;
• the target;
• authorization;
• intended actions;
• whether the request meaningfully enables harmful cybersecurity activity.

They should not classify ordinary local software architecture or diagnostics as cybersecurity activity merely because security-adjacent vocabulary appears in the prompt.

They should also distinguish between:

• discussing why a safety classifier produced a false positive;

and

• actually requesting harmful cybersecurity assistance.

Finally, if an additional safety check clears a request, the original reasoning/task should resume automatically rather than ending in "Reasoning stopped" and requiring another user turn.

---

Actual behavior

Observed behavior includes:

• benign local-development tasks being classified as cybersecurity-related;
• wording generated by ChatGPT itself apparently triggering the downstream classifier;
• repeated checks after an earlier false positive;
• checks continuing across model changes, including GPT-5.6 Sol;
• checks appearing on unrelated benign prompts;
• Astra Pro reasoning sometimes terminating instead of resuming after a safety check.

---

Possible areas to investigate

I would appreciate investigation into whether there is a regression involving one or more of the following:

1. False-positive cybersecurity classification of benign software-engineering terminology.
2. Context propagation between ChatGPT, Work, and Codex.
3. Account-level or cross-conversation safety state becoming overly conservative after an initial false positive.
4. Discussion of a previous false positive contributing to subsequent classifier escalation.
5. Mismatch between terminology generated by ChatGPT and terminology treated as suspicious by downstream safety classifiers.
6. Failure to resume Astra Pro reasoning after a safety check completes.

---

Additional notes

I did not capture exact timestamps or screenshots for every occurrence because the first incidents appeared to be isolated false positives. The problem only later became persistent enough to make normal use difficult.

The sequence above reflects the actual order in which the problem developed.

I have also contacted OpenAI Support regarding the issue.

I can provide additional examples from future occurrences if required.

What steps can reproduce the bug?

The issue appears to be stateful/intermittent rather than 100% deterministic, but the observed sequence was:

1. In Codex with GPT-5.6 Sol, run a benign task in my own local repository concerning an internal diagnostics module. The task contains no external target, network activity, exploitation, credentials, malware, or unauthorized access.
2. The task triggers an additional cybersecurity safety check / interruption.
3. Open ChatGPT with Astra and paste the previously blocked benign task only to ask why the safety classifier may have flagged it.
4. Continue using ChatGPT and Codex normally, including unrelated benign prompts and GPT-5.6 Sol.
5. Observe that additional cybersecurity checks begin occurring on a very large proportion of subsequent benign turns, often causing multi-minute delays.
6. In a separate Codex task, ask ChatGPT/Work to formulate ordinary ownership boundaries between two internal modules of the same project. The model-generated task uses terms such as "attack", "forgery" and "introspection" as architecture terminology.
7. Attempt to run the task and observe repeated cybersecurity checks (approximately three times in this incident).
8. On Astra Pro, when an additional safety check occurs during a reasoning/research run, the original turn may fail to resume after the check and instead end with "Reasoning stopped".
9. A new user message is then required to continue/recover the interrupted Astra Pro task.

The near-every-turn behavior later became less frequent without any configuration change, so the issue may depend on temporary account-level/cross-conversation safety state and may be difficult to reproduce from a clean account immediately.

What is the expected behavior?

Clearly benign local software-engineering tasks should not trigger cybersecurity additional safety checks solely because they contain security-adjacent terminology.

Discussing or quoting a previous false-positive safety classification in order to understand or report it should also not cause subsequent unrelated benign prompts to be subjected to near-every-turn cybersecurity review across ChatGPT, Codex, models, or conversations.

Safety classification should primarily consider the actual requested capability, target, authorization context and intended actions, rather than isolated words such as "attack", "forgery" or "introspection" when those words are being used in ordinary software-architecture contexts.

If an additional safety check clears a request, the original turn should resume automatically. Astra Pro reasoning should not end with "Reasoning stopped" and require an additional limited user turn merely to recover from the safety check.

Additional information

Related: #43208 and other recent safety-check reports, although this report also covers GPT-5.6 Sol, cross-surface behavior between ChatGPT and Codex, and failed Astra Pro resume after a safety check.

The report names no repository files, tests, or entry points. Start by following the listed Codex and Astra reproduction sequence and inspect the safety-check and reasoning-resume paths implicated by the behavior. Done means benign local-development prompts no longer trigger repeated checks and a cleared Astra Pro check resumes the original turn.