›_ Codex Issues
Codex Issues / #23220

Critical: persistent false-positive cyber-safety flags block normal GSM/DevOps workflows; Trusted Access and support cannot unblock

Resolved 💬 5 comments Opened May 18, 2026 by jyongchul Closed May 18, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

This is a follow-up to the closed issue #22988. The underlying problem is still active and materially blocking paid, normal development work.

The account continues to receive repeated cybersecurity-risk warnings during ordinary professional development and server administration work. The most recent screenshot shows Codex repeatedly printing both:

  • This chat was flagged for possible cybersecurity risk
  • Your conversations have multiple flags for possible cybersecurity risk. Responses may take longer because extra safety checks are on.

This is happening in routine project work, including GCP Secret Manager (GSM) credential hygiene and runtime-secret management, not offensive security work.

Why this should be treated as critical

This is not a cosmetic warning. It creates a closed failure loop for paying users:

  1. Normal development/admin workflows are flagged and slowed or interrupted.
  2. The warning points users to Trusted Access for Cyber.
  3. Trusted Access cannot be started for this account: We couldn't start verification. You may not be eligible for this verification flow right now.
  4. OpenAI Help Center case 08901525 says support cannot manually remove the warning or directly enable Trusted Access eligibility.
  5. The original GitHub issue #22988 was closed even though the workflow is still degraded.

GCP GSM / Secret Manager false-positive pattern

The false positives appear especially common during GCP GSM-related work, such as:

  • checking whether Secret Manager entries exist,
  • moving plaintext credentials into GCP Secret Manager,
  • verifying that runtime code resolves GSM: or GSM_FILE: references,
  • confirming that logs do not print secret values,
  • replacing hardcoded credentials with Secret Manager lookups,
  • validating PM2/MCP runtime secret materialization paths.

These are defensive credential-hygiene and infrastructure-hardening tasks on systems and repositories we own or administer. They are the opposite of credential theft. No raw secrets are being requested for disclosure in the issue, and the workflow intentionally avoids printing or storing secret values.

The classifier appears to be conflating legitimate secret-management/hardening language with malicious credential activity.

Current impact

  • ChatGPT Pro paid workflow is degraded during regular business/dev work.
  • Codex sessions repeatedly show the cyber-risk warning, sometimes multiple times in the same workflow.
  • Normal work such as Git sync, GCP Secret Manager hygiene, MCP/PM2 runtime checks, DNS/email configuration, and repo maintenance becomes unreliable.
  • The advertised remediation path is blocked.
  • Support has no manual unblock path.

Requested remediation

Please reopen #22988 or keep this issue open until there is a real remediation path.

Requested actions:

  1. Provide an official path for users whose normal workflows are falsely flagged but whose Trusted Access flow cannot start.
  2. Stop applying account-level degradation to unrelated normal development workflows when the underlying activity is authorized defensive/admin work.
  3. Add clearer classifier handling for GCP Secret Manager / GSM / credential-hygiene workflows so Secret Manager use is not treated as suspicious by default.
  4. Provide a way to submit Codex conversation/session IDs for classifier correction without requiring users to publicly expose private infrastructure details.
  5. Provide compensation for affected paid users whose regular work has been blocked or degraded, such as a prorated refund, account credit, or API credits.

We are specifically asking OpenAI to consider prorated refund or API/account credit compensation because paid service utility has been materially reduced by a false-positive classifier loop with no functioning unblock path.

Evidence

  • Original closed issue: #22988
  • Related reports: #22554, #19204
  • Help Center case: 08901525
  • Screenshot from 2026-05-18 Asia/Seoul: repeated cyber-risk warnings in Codex during normal project workflow. I will attach the screenshot to this issue/comment if GitHub upload is available from the current client.

Scope clarification

This report is not requesting bypass of safety systems. The work is authorized defensive/admin work on systems, repositories, domains, and infrastructure we own or operate. The problem is that legitimate paid usage is being repeatedly degraded, and the only advertised verification path is unavailable.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #22988
  • #22554
  • #22271
  • #22043

Powered by Codex Action

jyongchul · 3 months ago

Thanks for the duplicate detection. I reviewed the linked issues and this should remain open as a follow-up / escalation rather than being closed as a duplicate.

Why this is not fully covered by the linked issues:

  • #22988 is the original report, but it was closed while the account/workflow problem is still active.
  • The new evidence is from 2026-05-18 Asia/Seoul and shows repeated warnings still occurring in Codex during normal project work.
  • The current report adds a specific recurring false-positive pattern around GCP Secret Manager / GSM credential-hygiene workflows: checking secret existence, moving credentials into GSM, verifying GSM: / GSM_FILE: runtime resolution, confirming logs do not print secrets, and validating PM2/MCP secret materialization.
  • OpenAI Help Center case 08901525 has now said support cannot manually remove the warning or directly enable Trusted Access eligibility, so the advertised remediation path remains blocked.
  • This issue also requests an official remediation path and compensation options such as prorated refund, account credit, or API credits for paid users whose normal work is degraded by the false-positive loop.

The linked issues are related and useful context, but this issue tracks the unresolved post-closure state plus the GSM/Secret Manager false-positive pattern and the lack of an available support/Trusted Access unblock path. Please keep this open or link it as the active tracking issue rather than closing it as a duplicate.

jyongchul · 3 months ago

I need to strongly object to this issue being closed again without any visible human explanation, without confirmation that the underlying problem is resolved, and without providing an alternate active tracking path.

The problem is still happening. The 2026-05-18 Asia/Seoul screenshot evidence shows Codex repeatedly displaying:

  • \"This chat was flagged for possible cybersecurity risk\"
  • \"Your conversations have multiple flags for possible cybersecurity risk. Responses may take longer because extra safety checks are on. To get authorized for security work, join the Trusted Access for Cyber program: https://chatgpt.com/cyber\"

This is occurring during normal paid professional work: project maintenance, Git state checks, support-report preparation, and GCP Secret Manager / GSM credential-hygiene workflows such as verifying secret presence, moving credentials into GSM, checking runtime secret resolution, and confirming that logs do not expose secret values. This is authorized defensive/admin work on systems and repositories I own. It is not offensive security work.

Closing #23220 after #22988 was already closed creates a support deadlock:

  • GitHub issue #22988 was closed while the problem remained active.
  • This follow-up issue #23220 was also closed while the problem remained active.
  • Help Center case 08901525 says support cannot manually remove or bypass the warnings.
  • Trusted Access cannot even start for this account because the flow says verification may not be available.

That leaves a paid ChatGPT Pro user with degraded normal workflow, no usable self-service remediation path, no public resolution explanation, and no compensation path. This is unacceptable product/support behavior for a paid developer workflow.

Please do one of the following:

  1. Reopen #23220 as the active bug report, or identify the official active tracking issue where this exact post-closure / GSM false-positive / Trusted Access-ineligible state is being handled.
  2. Explain why the issue was closed despite the problem still reproducing.
  3. Provide a concrete remediation path or timeline.
  4. Provide compensation for the paid service degradation, such as a prorated refund, account credit, or API credits.

Screenshot note: I have the PNG evidence file from 2026-05-18 locally and attempted to attach it, but GitHub CLI does not provide a direct issue-attachment upload path. The relevant warning text from the screenshot is transcribed above so the evidence is preserved in this issue thread.

jyongchul · 3 months ago

Adding the 2026-05-18 screenshot evidence as requested, because the problem remains active after this issue was closed:

!2026-05-18 Codex false-positive cyber-safety warning during normal GSM/DevOps work

Source file is hosted publicly here for transparency: https://github.com/jyongchul/codex-false-positive-evidence/blob/main/screenshots/2026-05-18_10-20.png

This screenshot shows repeated warnings during normal development/operations work, including the banner text:

  • "This chat was flagged for possible cybersecurity risk"
  • "Your conversations have multiple flags for possible cybersecurity risk. Responses may take longer because extra safety checks are on. To get authorized for security work, join the Trusted Access for Cyber program."

Please reopen or provide the official active tracking path, and please address the requested prorated refund/account credit/API credit for the paid-service degradation.

jyongchul · 3 months ago

Update: the issue is still not resolved as of 2026-05-19 Asia/Seoul.

I opened a consolidated follow-up with the current affected thread/session ID, account ID, and new screenshots here: #23381

Current affected thread/session ID:

019e39d4-e755-7cb0-9fbc-d255c92f85d0

Affected account: jyongchul@live.com

New 2026-05-19 screenshot evidence:

Please do not treat the original reports as resolved; the warning loop is still actively blocking normal paid developer/admin work.