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_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 5 days ago

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

  • #40160
  • #39942
  • #40001
  • #40061

Powered by Codex Action

rootkiller6788 · 5 days ago

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.rs is a
different mechanism entirely — it only governs patch approval vs the
sandbox).

What actually happens in the client:

  • The Responses API returns response.failed with `error.code ==

"cyber_policy". The CLI maps this to ApiError::CyberPolicy
(
codex-rs/codex-api/src/sse/responses.rs:692, :420-422`).

  • The TUI renders it as the "This content can't be shown" notice via

new_cyber_policy_error_event()
(codex-rs/tui/src/history_cell/notices.rs:104-108).

  • A second, softer path exists: the backend can instead reroute to a

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:

  1. Surface the specific failure (cyber_policy vs the bio/misalignment

policy 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.

  1. Add a self-service way to declare "defensive security on my own

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.

Ghostbird · 21 hours ago

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.