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

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.