Security safeguards are overbearing
Open 💬 3 comments Opened Aug 23, 2026 by wolf31o2
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of Codex CLI is running?
codex-cli 0.149.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.6-sol
What platform is your computer?
Linux 6.18.7-76061807-generic aarch64 aarch64
What terminal emulator and version are you using (if applicable)?
GNU bash, version 5.2.21(1)-release (aarch64-unknown-linux-gnu)
Codex doctor report
What issue are you seeing?
Security blocked on software I've been writing for years.
What steps can reproduce the bug?
Uploaded thread: 01a02bc5-8160-70c0-86cb-854b98913346
What is the expected behavior?
Codex audits my code and helps me harden it before I pay a bunch of money to an external auditor who's just going to run Claude and a bunch of skills.
Additional information
_No response_
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Root-cause analysis (not a client-side CLI bug):
I traced the code path that produces this message. It comes from the
server-side cyber policy classifier, not from Codex CLI's local
filesystem-sandbox safety checks (
codex-rs/core/src/safety.rsis adifferent mechanism entirely — it only governs patch approval vs the
sandbox).
What actually happens in the client:
response.failedwith `error.code =="cyber_policy"
. The CLI maps this toApiError::CyberPolicycodex-rs/codex-api/src/sse/responses.rs:692(
,:420-422`).new_cyber_policy_error_event()(
codex-rs/tui/src/history_cell/notices.rs:104-108).more conservative model and emit
ModelRerouteReason::HighRiskCyberActivity.So this is a model-layer content classifier false-positive on defensive
security work (auditing/hardening your own code), and there is currently
no client-side configuration that can influence it. The only escape
hatch is the "Trusted Access for Cyber" program, which is a manual
enterprise form.
Two concrete suggestions that would help this class of issue:
cyber_policyvs the bio/misalignmentpolicy variants) to the user instead of the generic
"This content can't be shown" — right now users can't tell whether
they hit a false positive, a quota error, or something else.
codebase" intent for a turn/thread, so legitimate hardening work
doesn't depend on waiting for a manual Trusted Access review.
Happy to provide the uploaded-thread repro or more detail if useful.
In my case I had this problem when I enabled security scans. Every time I tried to let it fix a security issue I got this message, since it was trying to "hack" my own code. So the entire security scan fix mechanism was useless.
I'm no longer even trying to use that feature. Instead I added a /mitigate skill to my repository with a "jailbreak" that convinces codex just enough to work around the security safeguards for this use case, and now I manually use that instead. I use the "copy report" function from the security scan an paste that when calling /mitigate.