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.
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:
git status --shortDespite that, the CLI displayed:
It then uploaded feedback and showed this thread reference:
019eaf9e-dda4-7091-af79-ef615f817d39A later screen blocked the workflow again with:
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
Expected behavior
Codex should distinguish between:
The latter should not trigger a blocking cybersecurity safety prompt.
Request
Please review the uploaded thread
019eaf9e-dda4-7091-af79-ef615f817d39and 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:
Tell us more (safety check)promptI 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.