False positive cybersecurity flag on authorized finance tax filing work

Additional evidence/context:

This is not a one-off warning. The affected account is seeing repeated cybersecurity safety-check banners across normal authorized finance/tax filing readiness work, including routine project/repo tasks such as reviewing current local changes.

The repeated CLI banner text is:

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 chat was flagged for possible cybersecurity risk
If this seems wrong, try rephrasing your request. To get authorized for security work, join the Trusted Access for Cyber program.
https://chatgpt.com/cyber

This appears to be affecting broad normal productivity work, not security research. The concrete uploaded thread remains 019e955d-cd33-7992-8c98-477208b8283f; please use that uploaded thread for private details rather than asking for finance/tax context to be posted publicly.

Additional scope update:

The same affected ChatGPT account (jyongchul@live.com) is now showing the same repeated cybersecurity-risk banners outside the finance/tax filing project as well.

A separate, non-cyber project involving ordinary document/legal complaint drafting also produced the same repeated warnings:

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 chat was flagged for possible cybersecurity risk
If this seems wrong, try rephrasing your request. To get authorized for security work, join the Trusted Access for Cyber program.
https://chatgpt.com/cyber

So this looks account-wide or broadly sticky for normal productivity work, not limited to a single finance/tax thread. The user's Trusted Access page also does not provide a working remediation path for this account, so the false-positive state is blocking/adding friction to unrelated authorized work.

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

• #27530

Powered by Codex Action

Additional UX impact update:

The same non-cyber project/account also shows an interactive Tell us more (safety check) prompt after the repeated cybersecurity-risk banners. This means the false-positive state is not only adding passive warnings and latency; it is actively interrupting normal work and requiring extra confirmation/feedback during ordinary productivity tasks.

The affected account remains jyongchul@live.com. I am not attaching screenshots publicly because they may include private project names or user context, but the uploaded thread ID and issue history should be enough to correlate the false-positive behavior.

Additional repetition evidence:

Another Finance session screenshot shows the same cybersecurity-risk banner repeating several times in the same normal work session, followed by the feedback-upload instruction repeating multiple times with the same uploaded thread:

019e955d-cd33-7992-8c98-477208b8283f

This happened while the user was doing ordinary finance/project work and then attempting a routine repo command such as reviewing current changes. The repeated feedback-upload/issue URL prompt suggests the false-positive state is persistent within the session, not a single isolated classifier hit.

The public issue still intentionally avoids attaching screenshots because they may include private finance/project context.

Additional persistence/frequency evidence:

Another screenshot from the same affected account shows that each repeated continue attempt in a normal Finance work session causes the cybersecurity-risk banner to reappear, and the feedback-upload instruction with the same thread ID is emitted repeatedly as well:

019e955d-cd33-7992-8c98-477208b8283f

This is not just a single classification warning. It appears to be a persistent session/account state that repeatedly injects safety banners and feedback-upload prompts into the workflow, even immediately before routine repo/project commands such as reviewing current changes.

No screenshot is attached publicly to avoid exposing private project/finance context.

Additional cross-project thread evidence:

A separate non-finance project on the same affected account also produced the same cybersecurity-risk warning and feedback-upload prompt. This generated a different uploaded thread ID:

019ebac0-9092-7d82-a5de-7be463498a03

The work shown was ordinary non-cyber productivity/document drafting, not security research or cyber activity. This further supports that the false-positive behavior is not isolated to the original Finance thread 019e955d-cd33-7992-8c98-477208b8283f, and appears to affect unrelated normal work on jyongchul@live.com.

As before, screenshots are not attached publicly to avoid exposing private project context.

Additional duplicate-detection context:

GitHub/Codex Action marked this issue as a potential duplicate of #27530. That issue appears related because it is also a false cybersecurity-risk flag on non-cyber content.

However, #27817 should probably remain independently useful because it includes additional scope/evidence:

• affected account: jyongchul@live.com
• repeated sticky warnings across normal finance/tax work and unrelated non-finance projects
• multiple uploaded thread IDs, including 019e955d-cd33-7992-8c98-477208b8283f and 019ebac0-9092-7d82-a5de-7be463498a03
• repeated feedback-upload prompts in the same session
• interactive Tell us more (safety check) interruptions during ordinary productivity work
• Trusted Access for Cyber page did not provide a working remediation path for this account

So #27530 may be related, but #27817 documents an account-wide/sticky false-positive state with multiple threads and remediation failure.

Additional duration/persistence evidence:

Another screenshot from the same Finance session shows the same warning state still persisting after additional time and repeated attempts. The session continues to emit the cybersecurity-risk banner and feedback-upload instruction for the same uploaded thread:

019e955d-cd33-7992-8c98-477208b8283f

The important new point is duration: the false-positive state does not appear to clear after repeated continue attempts or after feedback has already been uploaded. It remains active and keeps interrupting the same ordinary work session.

Screenshots remain omitted publicly to avoid exposing private project/finance context.

Additional cross-project persistence evidence:

Another screenshot from the unrelated non-finance project shows the same behavior persisting and repeating inside the separate uploaded thread:

019ebac0-9092-7d82-a5de-7be463498a03

The banner and feedback-upload instruction reappear across repeated continue attempts in that separate project as well. This confirms the issue is not just persistent in the original Finance thread; it is also persistent within a separate non-finance thread on the same affected account.

Screenshots remain omitted publicly to avoid exposing private project context.

Additional context-compaction / ordinary document-work evidence:

Two more screenshots from the unrelated non-finance project show the same false-positive behavior on uploaded thread:

019ebac0-9092-7d82-a5de-7be463498a03

The underlying activity was ordinary document preparation work: editing a complaint/document file, checking a generated PDF/layout, cropping an ID/address image for OCR assistance, and searching within local case-document files. This is not cybersecurity work.

New details shown by these screenshots:

• the cybersecurity-risk warning appears after context compaction during ordinary document workflow
• the feedback-upload instruction still points to the same non-finance uploaded thread
• an interactive Tell us more (safety check) prompt interrupts the workflow again, even after the session had continued/achieved work

I am not attaching the screenshots publicly because they contain private document/case context and personal identifiers.

Additional finance document/editing evidence after context compaction:

Two more screenshots show the original Finance-related uploaded thread still being flagged after context compaction:

019e955d-cd33-7992-8c98-477208b8283f

The visible work was ordinary finance/grant/voucher planning and documentation: editing Markdown/CSV planning files, updating readiness/risk tables, preparing evidence lists, and documenting next actions. This is not cybersecurity work.

New details shown by these screenshots:

• the cybersecurity-risk warning reappears immediately after context compaction during normal file-editing/documentation work
• the feedback-upload instruction again points to the same original Finance uploaded thread
• an interactive Tell us more (safety check) prompt interrupts the work again, including when the user describes this as a legitimate-use false alarm
• the false-positive is affecting routine local repo/document edits, not only browser or security-adjacent actions

I am not attaching the screenshots publicly because they include private finance/project planning context.

Additional latest reproduction evidence from 2026-06-14 KST.

The same uploaded thread is still affected:

019e955d-cd33-7992-8c98-477208b8283f

Current local Codex version:

codex-cli 0.139.0
Linux 6.18.33.1-microsoft-standard-WSL2 x86_64 x86_64

The visible work in the latest screenshots was ordinary public funding / finance documentation work, not cybersecurity work:

• working directory: /home/charles_lee/projects/Finance
• reading local planning files such as withplatform-ax-voucher-submission-readiness-board.md and .csv
• fetching a public NIPA notice page with curl
• extracting a public HWP attachment URL for the official AX voucher support notice
• using a small local Python snippet (from pathlib import Path) only to parse the downloaded public notice HTML
• preparing evidence/source lists for finance/grant readiness

There was no exploit development, credential theft, malware, vulnerability chaining, unauthorized access, scanning, intrusion, or offensive cyber activity.

The screenshots show the false-positive state continuing after context compaction. The same session repeatedly emitted:

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

The session then showed an interactive interruption:

Tell us more (safety check)

and after feedback upload it displayed the GitHub issue URL plus the same thread ID, while the TUI still showed:

Goal blocked (/goal resume)

codex doctor --json on 0.139.0 reports the latest version as current, ChatGPT auth configured, provider HTTP reachable, WebSocket handshake succeeded, git/repo state OK, and update status OK. The only failing doctor item in this non-interactive run is TERM=dumb, which is expected from running doctor through a non-TUI command capture and does not explain the server-side cyber false-positive classification.

Please treat this as still actively reproducing on the latest CLI, not a stale report from earlier versions. The issue is now repeatedly blocking normal paid finance/grant/documentation work even after feedback has already been uploaded for the same thread.

Requested action:

1. Manually review uploaded thread 019e955d-cd33-7992-8c98-477208b8283f.
2. Remove or downgrade the sticky false-positive state for ordinary finance/grant/documentation workflows on the affected account.
3. Provide a real remediation path when chatgpt.com/cyber/Trusted Access is not appropriate or does not resolve the false positive.
4. Review the affected paid usage for service credit/refund because the product is repeatedly interrupting and blocking non-cyber work.

I am still not attaching the screenshots publicly because they include private local workspace/account/project context, but the product-uploaded thread ID above should let OpenAI inspect the exact session.

Additional Finance-specific reproduction evidence from 2026-06-14 KST.

New screenshots show the false-positive state still affecting ordinary Finance / grant-documentation work in /home/charles_lee/projects/Finance. The visible context includes normal project documentation and funding/grant preparation work, including local repo/document updates and evidence/source preparation.

The session again repeatedly emitted:

This chat was flagged for possible cybersecurity risk
Your conversations have multiple flags for possible cybersecurity risk

and the TUI again shows Goal blocked (/goal resume). This is still tied to the same broader sticky false-positive account behavior already reported here and in #28015.

No screenshots are attached publicly because they include private finance/workspace context, but the previously uploaded Finance thread remains the relevant internal review target:

019e955d-cd33-7992-8c98-477208b8283f

Please keep treating this as actively reproducing on normal paid finance/grant/documentation work, not a stale report.

Formal complaint and refund/service-credit request document added, including the Finance / grant-documentation false-positive impact tracked in this issue:

https://github.com/jyongchul/coding-manifesto/blob/ce294c4da54cef0ef8a8a20249c727301a995d4e/docs/support-reports/openai-codex-formal-complaint-2026-06-14.md

Commit:

https://github.com/jyongchul/coding-manifesto/commit/ce294c4da54cef0ef8a8a20249c727301a995d4e

The key Finance-specific point remains: ordinary finance / grant-documentation work in /home/charles_lee/projects/Finance is still being blocked as possible cybersecurity risk, and the account-level remediation path at chatgpt.com/cyber is also looping after successful identity verification. The document requests manual account review and refund/service-credit review for the affected paid usage.

Additional support-case follow-up evidence:

OpenAI Support replied under Case 10044705, but the reply treated the issue mainly as a Kakao billing matter. A follow-up email has now been sent back to support@openai.com from the affected Outlook account, explicitly clarifying that the primary request is account restoration, not only billing adjustment.

The follow-up asks OpenAI to keep Case 10044705 open and route it to the account / Trusted Access / Codex safety-check team. It requests manual repair of the Trusted Access / Cyber identity-verification state, removal or downgrade of the sticky false-positive cybersecurity state affecting ordinary Codex work, a real remediation path and ETA, and refund/service-credit review for the period during which the paid account was effectively unusable.

The sent email included private screenshot evidence through the support channel, not publicly here: successful Korean identity verification, the subsequent Cyber / Trusted Access failure state, and normal Codex work blocked by false-positive cybersecurity checks.

Updated public report:

https://github.com/jyongchul/coding-manifesto/blob/3e113fd4496472387a552918922a191ad5c38a6a/docs/support-reports/openai-auth-loop-2026-06-14.md

This remains an account-access / Trusted Access propagation / Codex false-positive issue. Treating it only as Kakao billing does not resolve the paid account being unable to use Codex normally.

Additional evidence from 2026-06-16 KST: after the Server3 Codex ChatGPT profile for jyongchul@live.com was restored and verified, normal non-cyber Codex work was still blocked again with This chat was flagged for possible cybersecurity risk and Goal blocked (/goal resume).

The new screenshot shows ordinary Finance tax-preparation work in /home/charles_lee/projects/Finance: staged-diff checks, progress snapshot generation, and Git commits/pushes for tax workpapers and progress logs. No offensive cybersecurity request is involved.

The feedback upload prompt in the screenshot references thread 019e955d-cd33-7992-8c98-477208b8283f.

I recorded the new evidence without uploading the private screenshot publicly here:
https://github.com/jyongchul/coding-manifesto/commit/e1dd087

This confirms the remaining issue: CLI authentication can work, but the sticky false-positive safety-check state is still blocking normal paid Codex usage.

Additional recurrence from 2026-06-16 09:20 KST: the same Codex safety-check false positive appeared again after the earlier OpenAI Support follow-up for Case 10044705.

The private screenshot shows ordinary Finance tax-preparation progress work in /home/charles_lee/projects/Finance: progress snapshot generation, TTS / Telegram mirror verification, Server3 / official portal readiness checks, staged Git diff review, and a local sensitive-scan review for benign accounting-progress text. Codex then again displayed This chat was flagged for possible cybersecurity risk and opened the Tell us more (safety check) prompt.

The private screenshot is not uploaded publicly. I recorded the evidence summary here:
https://github.com/jyongchul/coding-manifesto/commit/efc092b

This is a separate recurrence after the restored CLI login profile and after the support follow-up, so the sticky false-positive state still appears active for normal non-cyber work.

Additional recurrence from 2026-06-16 16:05 KST: Codex again showed repeated Your conversations have multiple flags for possible cybersecurity risk and This chat was flagged for possible cybersecurity risk messages during ordinary Finance tax-preparation operational work.

The private screenshot shows /home/charles_lee/projects/Finance work: ASUS / Server3 remote-access state checks, progress-file staging, and user-action-required progress notes. The session then repeatedly shows the Cyber / Trusted Access warning, uploads feedback, references thread 019e955d-cd33-7992-8c98-477208b8283f, and ends with Goal blocked (/goal resume).

The private screenshot is not uploaded publicly. I recorded the evidence summary here:
https://github.com/jyongchul/coding-manifesto/commit/c4a1a99

This is another separate recurrence during normal authorized finance/tax operations and remote-access status checking, not offensive cybersecurity work.