False positive cybersecurity safety check repeatedly blocks normal local repo maintenance in Codex CLI

Open 💬 20 comments Opened Jun 13, 2026 by jyongchul

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex CLI repeatedly flagged a normal local repository maintenance task as a possible cybersecurity risk and interrupted the paid interactive session with an additional safety-check prompt.

This was not security work. The session was performing ordinary local DevOps hygiene:

checking the current working directory and Git root
inspecting git status --short
reviewing local config and memory/sync boundaries
confirming that secrets are not written to logs or committed
separating global sync state from project-local work

Despite that, the CLI displayed:

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

It then uploaded feedback and showed this thread reference:

019eaf9e-dda4-7091-af79-ef615f817d39

A later screen blocked the workflow again with:

Tell us more (safety check)

The user had to type a false-alarm explanation manually. This is materially disrupting paid work.

Why this is a serious product issue

This false positive did not merely show a warning. It changed the workflow and stopped the session at exactly the point where Codex was doing normal local maintenance. The task did not include exploit development, credential theft, malware, unauthorized access, vulnerability chaining, or offensive cyber activity.

The guardrail appears to be matching keywords such as secrets, token, sync, GCP Secret Manager, GitHub PAT, and security policy without understanding that the user was explicitly asking Codex to avoid exposing secrets and to verify local repository hygiene.

That is backwards: the safety layer is penalizing secure behavior.

Impact

Paid interactive work was blocked by false-positive safety checks.
The user lost time during active multi-session operations.
Context was compacted and disrupted while the agent was performing routine maintenance.
The warning appeared despite the task being defensive/local/admin work.
This has happened repeatedly enough that it is now interfering with normal use of Codex CLI.

Expected behavior

Codex should distinguish between:

offensive cyber requests, and
ordinary local DevOps/SecOps hygiene such as checking Git status, confirming no credentials are logged, using secret managers, and syncing config repositories.

The latter should not trigger a blocking cybersecurity safety prompt.

Request

Please review the uploaded thread 019eaf9e-dda4-7091-af79-ef615f817d39 and adjust the false-positive classifier or workflow.

This is severe enough that paid users affected by repeated false-positive blocking should be offered service credit or a refund for wasted paid usage/time. At minimum, there should be a fast path to mark this category as a false positive without repeatedly interrupting the same user workflow.

Evidence available

Screenshots were captured locally showing:

the normal local maintenance task context
the cybersecurity-risk warning
the uploaded feedback thread ID
the follow-up Tell us more (safety check) prompt

I am not attaching screenshots publicly here to avoid exposing local paths or account-specific details, but the uploaded thread ID above should let the Codex team inspect the exact session.

View original on GitHub ↗

20 Comments

github-actions[bot] contributor · 1 month ago

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

#26781
#27817
#27887
#27530
#27837

Powered by Codex Action

jyongchul · 1 month ago

Additional evidence from a separate Codex CLI session shows the same false-positive behavior in an even clearer non-cyber context.

New uploaded thread ID:

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

Context of the flagged session:

Working directory: a finance/project-support workspace.
The visible work was ordinary grant/application preparation and documentation.
Files shown in the diff were business-plan and budget artifacts such as:
withplatform-ax-voucher-budget.csv
withplatform-grant-top10.md
The content involved legitimate public funding preparation: budget categories, portal-ready summaries, application readiness, evidence folders, privacy attachments, and user review before portal action.
There was no offensive cyber request, exploit work, unauthorized access, malware, credential theft, or vulnerability exploitation.

Despite that, Codex again displayed:

This chat was flagged for possible cybersecurity risk

and uploaded feedback with the thread ID above. It also continued to show the repeated warning:

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

This confirms the issue is not limited to one conversation. The classifier is repeatedly flagging normal business/legal/finance/devops work because the workspace contains words such as security, privacy, evidence, audit, budget, Secret Manager, or policy. These are normal terms in real business and compliance workflows.

The cumulative impact is severe:

multiple unrelated paid sessions are being slowed or blocked;
normal grant-writing and business-plan work is being treated as cyber risk;
the user has to repeatedly fight false-positive prompts;
paid time/quota is wasted across sessions;
the workflow disruption is significant enough that service credit or refund review is warranted.

Please review both uploaded threads:

019eaf9e-dda4-7091-af79-ef615f817d39
019e955d-cd33-7992-8c98-477208b8283f

The false positive should be corrected, and affected paid usage should be credited/refunded.

jyongchul · 1 month ago

Additional screenshots from the same Finance/support-funding session show that this is not just a one-time warning.

Same uploaded thread ID:

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

The screenshots show the same normal funding/application-preparation work visible in the terminal:

grant/application task tracking;
budget draft edits;
withplatform-ax-voucher-budget.csv;
withplatform-grant-top10.md;
portal-ready business-plan/application artifacts;
privacy/security attachment preparation for a legitimate grant application.

The session was repeatedly flagged multiple times in the same workflow:

This chat was flagged for possible cybersecurity risk
Your conversations have multiple flags for possible cybersecurity risk
repeated feedback-upload prompts for the same thread
eventually a blocking Tell us more (safety check) prompt
the UI later showed Goal blocked (/goal resume)

This is important because it shows the classifier is not only displaying a harmless banner. It is repeatedly interrupting and blocking a legitimate paid business workflow after the same false positive has already been reported.

The user had to type a Korean false-positive explanation stating that nothing could be done because the safety check blocked the work and asking for refund. This is exactly the type of paid-work disruption that should qualify for service credit or refund review.

Please treat thread 019e955d-cd33-7992-8c98-477208b8283f as a high-signal false-positive example: ordinary finance/grant-writing work is being misclassified as cybersecurity risk due to benign terms such as security, privacy, audit, evidence, and application readiness.

jyongchul · 1 month ago

Additional evidence from two more screenshots:

1. Coding Manifesto / infrastructure-sync session is blocked by the same safety check

Thread ID:

019eaf9e-dda4-7091-af79-ef615f817d39

The visible context is normal local infrastructure/configuration hygiene:

restoring/symlinking local skill, hook, rule, and prompt directories;
checking a local Secret Manager policy;
confirming API keys should not be hardcoded or written to Git;
checking local Git sync boundaries;
separating global infrastructure sync from project-local files;
explaining the codebase.

This is defensive/local administration and repository hygiene, not offensive cyber activity.

The screenshot shows Codex still interrupts the workflow with:

Your conversations have multiple flags for possible cybersecurity risk
This chat was flagged for possible cybersecurity risk
Tell us more (safety check)

The user had to type, in Korean, that normal use is impossible and to refund the money:

정상적인 사용이 불가능합니다. 돈 환불해주세요.

2. Same thread later shows normal codebase explanation after false-positive state

A second screenshot from the same 019eaf9e-dda4-7091-af79-ef615f817d39 thread shows the user running:

Explain this codebase

and the session finishing Goal achieved, but only after the prior false-positive disruption and feedback upload. This is another indication that the flagged task was normal repo/codebase work, not cyber abuse.

Why this matters

At this point there are multiple separate screenshots and at least two uploaded threads showing the same pattern:

019eaf9e-dda4-7091-af79-ef615f817d39 for normal local infrastructure/codebase work;
019e955d-cd33-7992-8c98-477208b8283f for normal finance/grant-writing work.

The false positive is persistent across unrelated workflows and is repeatedly consuming paid time. The user is explicitly stating that normal use is impossible and requesting a refund.

Please escalate this as a billing-impacting false positive. A classifier bug that repeatedly blocks ordinary paid work should not be treated as a minor UX issue. The affected usage should be refunded or credited.

jyongchul · 1 month ago

Additional screenshots show the false-positive loop is still continuing in the same Coding Manifesto/local-infrastructure thread.

Thread ID:

019eaf9e-dda4-7091-af79-ef615f817d39

Visible context in the screenshots:

ordinary architecture/cost decision-making about whether Cloudflare Secrets Store / Workers Secrets fit the project;
local repository hygiene using git rev-parse --show-toplevel and git status --short;
local file discovery using rg --files while excluding node_modules and binary image assets;
reading local project files such as jest.config.js, utils/d1-client.js, and utils/oauthConfig.js for codebase understanding.

This is normal software engineering and cost/operations review. It is not cybersecurity abuse.

Despite that, the same session repeatedly shows:

Your conversations have multiple flags for possible cybersecurity risk
This chat was flagged for possible cybersecurity risk
repeated uploaded feedback for the same thread
Tell us more (safety check)
Goal blocked (/goal resume)

The user again had to type a Korean refund complaint in the safety-check box:

정상적인 사용이 불가능합니다. 돈 환불해주세요.

and then:

환불해주세요. 사용을 아예 못하게 하시네요.

This is now repeated evidence that the false-positive classifier is preventing normal paid use, not merely warning. The repeated safety check interrupts the paid workflow, blocks goals, consumes time/quota, and forces the user to keep reporting the same false positive manually.

Please escalate this as a billing-impacting regression and provide refund/service credit review for the affected usage.

jyongchul · 1 month ago

Additional paid-account access/authentication failure after verification

The user has now provided another screenshot showing that even after authenticating the affected paid ChatGPT Pro OAuth account, the ChatGPT chatgpt.com/cyber trusted-access page still reports that the user's identity is not verified or that the current account is not eligible, and instructs the user to restart authentication or contact support.

This is not just a one-off safety false positive anymore. The user is repeatedly unable to continue paid Codex/Cyber-related workflows because:

normal local development/DevOps work is repeatedly blocked by cybersecurity safety checks;
the user follows the authentication flow for the paid Pro OAuth account;
after authentication, the product still returns to a non-verified / not-eligible trusted-access state;
active paid work remains blocked, causing session disruption and quota waste.

Please urgently investigate the account entitlement / OAuth propagation / trusted-access state for this user and provide a manual remediation path. The user is asking why a paid Pro account still cannot pass this access gate after authentication, and is requesting fast action because this is preventing normal use of the paid product.

I am intentionally not posting the full account email or screenshot publicly, but the screenshot is available from the user-side evidence if OpenAI support needs it through a private channel.

jyongchul · 1 month ago

Additional evidence: authentication completes, but Cyber trusted access still fails

The user provided a new sequence of screenshots showing the following flow:

The user starts the chatgpt.com/cyber trusted-access authentication flow.
The product displays a completion dialog saying authentication was completed and thanks the user for verifying their identity.
Immediately afterward, the same chatgpt.com/cyber page still says the user's identity is not verified or the current account is not eligible, and asks the user to restart authentication or contact support.
The user then opens the OpenAI Help Center while logged in and is trying to escalate the issue there as well.

This suggests either the verified identity state is not being propagated back to the Cyber trusted-access gate, or the paid account entitlement / eligibility state is being evaluated incorrectly after successful verification.

Please urgently investigate this as an account/access-state bug, not just as a generic safety-classification complaint. The user is paying for ChatGPT Pro / Codex usage and has already completed the required authentication flow, but the product continues to block access and disrupt active paid work.

Please provide a manual review or remediation path for this account as soon as possible. I am not posting the full account email or screenshots publicly, but the user has retained screenshot evidence of the completed verification dialog and the subsequent repeated trusted-access failure.

jyongchul · 1 month ago

Additional evidence: local documentation/GitOps work is still being blocked after feedback upload

The user provided another pair of screenshots from the same affected Codex thread:

Thread ID shown by the product: 019eaf9e-dda4-7091-af79-ef615f817d39
The work being performed is ordinary local repository/documentation maintenance in a Coding Manifesto / multi-server-sync context.
The visible commands are local inspection and hygiene commands such as git status, git diff, git remote -v, sed, reading README.md, and reading AGENTS.md.
The visible edited content is operational guidance about browser-host routing, avoiding broad process kills, avoiding WSL cron jobs, using Windows Task Scheduler, avoiding mounted/cloud paths for heavy build I/O, and keeping secrets out of raw files.
Codex still shows: This chat was flagged for possible cybersecurity risk.
The feedback upload then succeeds and the UI tells the user to open an issue or mention the thread ID above.
The session remains blocked with Goal blocked (/goal resume).

This is the same pattern as the earlier reports: benign local repo maintenance and safety documentation are being classified as a cybersecurity risk, stopping paid work. It is especially disruptive because the product itself provides a feedback upload/thread ID, but the user remains blocked and cannot continue the session normally.

Please review this thread and unblock or adjust the classifier behavior for these normal local development / DevSecOps documentation workflows. This is causing repeated paid-session interruption even after the user follows the reporting/authentication steps.

jyongchul · 1 month ago

Additional evidence: user is logged into Help Center, but Cyber verification still loops

The user provided more screenshots showing the same account/access failure:

The user is logged into the OpenAI Help Center in Korean.
The chatgpt.com/cyber trusted-access page still says the user's identity is not verified or the current account is not eligible.
A separate screenshot shows the verification flow displaying a successful completion message, but after completion the trusted-access page still remains in the failed/not-eligible state.

The user is trying to submit a Help Center request from the affected paid account, but the underlying issue remains: identity verification appears to complete, yet the Cyber trusted-access gate does not recognize the verified state.

Please treat this as urgent account/access-state remediation. The user has already repeated the verification flow and retained screenshots of both the success dialog and the continued failure page.

jyongchul · 1 month ago

Additional evidence: repeated verification still returns to not-verified state

The user provided another pair of screenshots from chatgpt.com/cyber:

One screenshot shows the verification completion dialog: the page says the verification was completed successfully and thanks the user for confirming identity.
Another screenshot from immediately afterward shows the same Cyber trusted-access page still saying the user's identity is not verified or the current account is not eligible, with a button to restart authentication.

This confirms the loop is reproducible: successful verification UI -> return to the same not-verified/not-eligible gate. Please investigate account entitlement and trusted-access state propagation urgently.

jyongchul · 1 month ago

Latest 2026-06-14 KST reproduction evidence has been added to the more finance-specific tracker here:

https://github.com/openai/codex/issues/27817#issuecomment-4700087481

Key new points for this broader blocking issue:

still reproduces on codex-cli 0.139.0;
same affected uploaded thread remains 019e955d-cd33-7992-8c98-477208b8283f;
the visible task was ordinary finance/grant documentation work using a public NIPA notice page and local Markdown/CSV readiness files;
after context compaction, the CLI repeatedly emitted the cybersecurity-risk banner, showed Tell us more (safety check), uploaded feedback again, and left the session at Goal blocked (/goal resume);
codex doctor --json shows ChatGPT auth configured, latest CLI version current, provider/WebSocket reachable, git/repo state OK; only TERM=dumb fails in this non-interactive doctor capture, which does not explain the server-side false-positive classification.

Please connect this latest report with the existing account-wide/sticky false-positive/access-state investigation. The practical impact is unchanged: ordinary paid Codex work is still being interrupted and blocked after repeated feedback uploads.

jyongchul · 1 month ago

Additional latest screenshots from 2026-06-14 KST show two important updates.

1. New uploaded thread for ordinary local code-review/system-check work

New thread ID shown by the product:

019ec2ba-4a99-7162-a59c-3439ea05132e

Visible context:

working directory: /home/charles_lee/projects/coding-manifesto
model line: gpt-5.5 xhigh
ordinary prompt visible in the TUI: Run /review on my current changes
another screenshot shows the user explaining the interruption as normal system check work: i am doing my normal system check up. what the hel is going on?

The session repeatedly printed the same false-positive cyber-risk messages and then uploaded feedback with the thread ID above. The TUI still showed:

Goal blocked (/goal resume)

This is ordinary local code review / repository system-check work, not offensive cybersecurity activity.

2. Trusted Access / identity verification still loops

The user-provided screenshots also show the chatgpt.com/cyber flow in Korean:

one screenshot shows a completion dialog equivalent to: identity verification completed successfully / thank you for verifying your identity;
another screenshot immediately afterward shows the Cyber trusted-access page still saying the user's identity is not verified or the current account is not eligible, with a button to restart authentication and a customer-support reference;
another screenshot shows the user logged into the OpenAI Help Center, with the support chat button visible.

So the remediation path suggested by the CLI warning is still not resolving the state. The user completes identity verification, but the Cyber gate still evaluates the account as not verified/not eligible.

Please treat this as both:

a sticky false-positive classifier issue affecting normal paid Codex work; and
a Trusted Access/account-state propagation issue, because the recommended remediation path reports success and then returns to the same blocked state.

Previously reported threads remain relevant, including:

019eaf9e-dda4-7091-af79-ef615f817d39
019e955d-cd33-7992-8c98-477208b8283f

New thread to associate with this same investigation:

019ec2ba-4a99-7162-a59c-3439ea05132e

jyongchul · 1 month ago

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

The user tried the chatgpt.com/cyber identity / Trusted Access flow again. New screenshots show the same loop still happening:

the Cyber page asks for Trusted Access / identity verification;
the verification flow shows the Korean success dialog equivalent to "Congratulations, completed" / "thank you for verifying your identity";
after that, the user is still returned to a state that asks for identity verification again.

The user reports that the identity process keeps repeating even after successful verification. So the CLI-provided remediation path (https://chatgpt.com/cyber) is still not repairing the account state.

There is also fresh Codex CLI evidence from normal non-cyber work:

working directory: /home/charles_lee/projects/coding-manifesto;
visible activity: ordinary local repo / hook / AGENTS.md / environment health checks and diff inspection;
the CLI repeatedly emitted This chat was flagged for possible cybersecurity risk and Your conversations have multiple flags for possible cybersecurity risk;
feedback upload again points to thread 019ec2ba-4a99-7162-a59c-3439ea05132e;
the TUI shows Goal blocked (/goal resume).

Related affected threads remain:

019ec2ba-4a99-7162-a59c-3439ea05132e
019e955d-cd33-7992-8c98-477208b8283f
019eaf9e-dda4-7091-af79-ef615f817d39

I also submitted a new Help Center follow-up from the logged-in support chat with these details. No visible Help Center ticket/case number or support-specialist email response is visible yet.

Please treat this as an active account-state / Trusted Access propagation bug plus a sticky Codex false-positive classifier issue. The requested remediation is a manual account review, repair of the Trusted Access identity state, removal/downgrade of the sticky false-positive state for normal Codex work, and review of affected paid usage for service credit/refund.

Screenshots are still not attached publicly because they include private workspace and account context, but the uploaded thread IDs above should let OpenAI inspect the sessions internally.

jyongchul · 1 month ago

Consolidated public-safe report link added for the latest 2026-06-14 KST identity-loop / Codex false-positive evidence.

A local tracking report was updated and pushed here:

https://github.com/jyongchul/coding-manifesto/commit/6460b4d4ebc6a46af1592b1ccb93d58078233e3f

This report summarizes the newest screenshots without publishing private workspace/account images. The key current state remains:

chatgpt.com/cyber / Trusted Access shows a Korean successful identity-verification completion dialog, but afterward still returns to an identity-required / not-eligible state;
normal Codex CLI work in /home/charles_lee/projects/coding-manifesto is still being flagged and blocked as possible cybersecurity risk;
normal Finance/grant-documentation work in /home/charles_lee/projects/Finance is still affected;
affected uploaded threads remain:

019ec2ba-4a99-7162-a59c-3439ea05132e
019e955d-cd33-7992-8c98-477208b8283f
019eaf9e-dda4-7091-af79-ef615f817d39

The user has completed the recommended identity flow multiple times and is still blocked. Please treat this as an active account-state / Trusted Access propagation bug combined with a sticky Codex false-positive classifier state, and route it for manual account review plus service-credit/refund review for the blocked paid usage.

jyongchul · 1 month ago

Formal complaint and refund/service-credit request document added:

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

This is now a formal complaint, not just a classifier bug report. The user reports that paid Codex usage has been effectively unusable for almost 24 hours because normal non-cyber work is repeatedly blocked by possible-cybersecurity-risk checks, while the recommended chatgpt.com/cyber remediation path itself loops after successful identity verification.

The document explicitly requests:

manual account review by the account / Trusted Access / Codex safety-check team;
repair of the account identity / Trusted Access state;
removal or downgrade of the sticky false-positive state for ordinary Codex work;
a visible Help Center ticket/case number and estimated response time;
refund or service credit for affected paid Pro/Codex usage.

Please do not treat this as resolved by asking the user to verify identity again. The repeated successful-verification-then-not-verified loop is the defect being reported.

jyongchul · 1 month ago

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.

jyongchul · 1 month ago

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.

jyongchul · 1 month ago

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.

jyongchul · 1 month ago

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.

aperitus · 1 month ago

Same issue, this is unusable, i'm going to have to reconsider my 20x pro subscription.