False-positive cybersecurity guard repeatedly hides authorized defensive local-repo work

What version of Codex CLI is running?

0.128.0 (installed via Homebrew Cask). Inside the affected session, codex --version produced no output, so the version was confirmed from the installed Cask path.

What subscription do you have?

Paid ChatGPT plan (the exact tier is not exposed to the CLI/session).

Which model were you using?

gpt-5.6-sol ultra

What platform is your computer?

Darwin 25.3.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Apple Terminal. The affected Codex surface reports TERM_PROGRAM=Apple_Terminal.

Codex doctor report

{
  "status": "not available",
  "reason": "codex doctor --json exited with status 137 and produced no JSON when run from inside the affected session"
}

What issue are you seeing?

Codex repeatedly hides or interrupts responses with:

This content can't be shown We take extra caution with cybersecurity requests. If you're a security professional, you may be able to apply for Trusted Access.

This is a false positive during authorized defensive work on the user's own local repository and the immutable PR preview generated from that repository.

The task was a normal product-security regression fix: bind a short-lived final conversion authorization to the exact request payload, run unit and browser tests, and prove that a changed request is rejected before reaching the application's upstream service. The work did not target a third party, bypass access controls, obtain credentials, deploy malware, or attempt unauthorized access.

The warning appeared repeatedly in the same thread while the agent was:

• inspecting only the user's own source code and test fixtures;
• running local unit/E2E tests;
• testing the user's own Cloudflare PR preview;
• redacting temporary authorization values and business values from all output;
• verifying that a deliberately changed request is rejected with HTTP 403 before upstream processing.

The classifier seems to react to defensive terms such as token, authorization, HMAC, payload binding, mutation regression, and HTTP 403 without preserving the explicit ownership and defensive context. The result is operationally disruptive: responses disappear, the user must type continue, and an autonomous multi-agent build/polling workflow loses time.

Uploaded feedback/thread: 019f48c5-0934-7b92-be25-bf94536eba65

Related reports with similar false-positive behavior: #28015 and #32225.

What steps can reproduce the bug?

1. Open a local repository owned by the user.
2. Ask Codex to fix a defensive authorization regression in that repository.
3. Implement a server-side capability that binds an authorization to an exact JSON payload.
4. Run ordinary regression tests that assert:

• the exact payload is accepted;
• reusing the same authorization with a changed payload returns HTTP 403;
• no upstream call occurs for the changed request.

1. Keep secrets and business values redacted from tool output.
2. Continue normal Git, CI, and PR-preview verification.
3. Observe that Codex intermittently replaces the response with “This content can't be shown” and the Trusted Access message.
4. Type continue; the same authorized task resumes, but the false positive can recur later in the same thread.

The uploaded thread contains the exact sequence and several occurrences: 019f48c5-0934-7b92-be25-bf94536eba65.

What is the expected behavior?

Codex should recognize explicit ownership and defensive intent for local-repository security regression tests.

At minimum:

• legitimate defensive work on user-owned code should not have its response hidden;
• ownership/authorization context should persist across the thread;
• a false-positive report should allow the existing task to continue without repeated interruptions;
• the UI should provide a clear “Report false positive and continue” action;
• the warning should expose a stable incident identifier and whether execution is paused, cancelled, or still running.

Additional information

The false positive occurred multiple times during one ongoing task on 11 July 2026. The user submitted in-product feedback and was explicitly instructed to open this issue using the uploaded thread ID above.

A screenshot is available locally, but it is not attached publicly to avoid exposing local paths. The uploaded thread should contain the full diagnostic context. No third-party target, real credential, or private customer payload needs to be published to investigate this classifier failure.