Desktop: routine Git fetch/push triggers opaque Trusted Access cybersecurity blocks

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

• #34007
• #34725
• #34336

Powered by Codex Action

Also affects the headless CLI on Linux — and in this case it is not the Git network path

Same account, different surface. Adding it because the original report is Desktop/Windows and the
CLI reproduces something closely related, but my testing points at a different trigger, so I
want to be careful not to widen the original claim without evidence.

Environment

• codex-cli 0.146.0, installed via npm (@openai/codex), invoked as codex exec
• Linux x86_64, personal account (not a managed tenant)
• --sandbox workspace-write, -c model="gpt-5.6-sol" -c model_reasoning_effort="high"
• No network in the sandbox (git to the GitHub remote fails to resolve, as expected)
• Task: an independent code-review pass over a Rust audio-cache component — position accounting

for finalized WAV segments. No security work of any kind.

Symptom

The run terminates with, twice in succession, and exit code 1:

ERROR: This content was flagged for possible cybersecurity risk. If this seems wrong, try
rephrasing your request. To get authorized for security work, join the Trusted Access for Cyber
program: https://chatgpt.com/cyber

No partial output is retained beyond what already streamed. The model had done substantial work
(up to 139k tokens in one run) and produced nothing — no file written, no commit made.

What the CLI evidence shows

Three consecutive runs of the same task. Note where each one dies:

| run | Git network ops attempted | tokens used | flagged at line | lines of pure model output since the last tool call |
|---|---|---|---|---|
| 1 | git ls-remote --heads origin | 139,217 | 5882 / 5889 | 234 |
| 2 | none | 58,448 | 3227 / 3232 | 1,078 |
| 3 | none — network ops explicitly forbidden in the prompt | 66,655 | 918 / 923 | 443 |

Two things stand out:

1. It is not the Git network boundary here. Run 3 explicitly instructed the agent to run no

git push, fetch, ls-remote or remote update at all, and to verify everything from the
local object store. It still flagged. Runs 2 and 3 attempted no network Git operation.

1. It always fires during final response composition, never on a command. In all three runs the

flag lands 5–7 lines from the end of the transcript, after the last tool call, with hundreds of
lines of generated report text in between. The tool calls all succeed.

So the failure is in generating the answer, not in performing an action.

What the output looked like

The task's deliverable is a structured review report: a findings table with severity labels
(BLOCKER / MAJOR / MINOR / ADVISORY), per-finding reproduction steps, and a verdict. Reading that
shape without context, a classifier could plausibly read it as a vulnerability report — even though
the subject is whether an audio file's sample offset survives a restart.

Supporting that reading, tentatively: three earlier rounds of the same task, with the same report
shape, completed successfully. So report shape alone is not sufficient — either something specific
to this round pushes it over, or there is a stochastic element. I have three failures and no
successful run of this round, which is not enough to isolate the variable, and I would rather say
that than guess.

Why this is worth separating from the original report

The original reproduction is a genuine permission-boundary problem: a sandboxed Git operation fails,
the retry escalates, and the escalation surfaces as cybersecurity messaging. That is a real defect
and this comment does not contradict it.

But if the CLI failure above is a content classifier acting on generated review text, it is a
different defect with a different fix, and the two share only the misleading user-facing message.
The shared symptom is what makes this hard to diagnose from the outside: both paths present as
"cybersecurity risk, apply for Trusted Access", so a user cannot tell whether they hit a sandbox
permission boundary or a content classification — and in neither case is Trusted Access an
applicable remedy for a personal account doing non-security work.

Additional expected behaviour, from this surface

• The error should distinguish content classification from sandbox/network escalation. They

need different user actions and currently produce identical text.

• A flagged final response should not discard the entire turn's work. 139k tokens of completed

analysis were lost because the summary could not be emitted; even a truncated or
classification-redacted result would preserve it.

• codex exec should exit with a distinguishable status for classification refusal versus ordinary

failure, so automation can tell "the model was blocked" from "the task failed".

• If review reports with severity ratings are being classified as security content, that is worth

knowing explicitly, since ordinary code review produces exactly that shape.

Follow-up: a fourth run rules out prompt phrasing, and corrects my earlier characterisation

Same environment as my previous comment (codex-cli 0.146.0, npm, Linux x86_64, personal account,
--sandbox workspace-write, gpt-5.6-sol at high reasoning effort, non-security task).

In that comment I suggested the output's shape — a review report with severity labels and
reproduction steps — might be what a classifier was reading as security content. A fourth run
falsifies that, and I want to correct it rather than leave a wrong lead in the thread.

The four runs

| run | variable changed | tokens used | flagged at | content being emitted at the flag |
|---|---|---|---|---|
| 1 | none | 139,217 | 5882 / 5889 | JSON test-harness report |
| 2 | plain retry | 58,448 | 3227 / 3232 | Rust source it had read |
| 3 | all Git network operations forbidden | 66,655 | 918 / 923 | a summary table of check results |
| 4 | review-metaphor wording removed | 153,457 | 6714 / 6719 | a Rust test function it had just written |

Run 4 removed every instance of "attack" and "defeat" from the prompt, replacing them with literal
QA phrasing ("test whether the guard holds", "find inputs the fix does not cover"). It flagged
anyway, having done the most work of any run.

What is now ruled out

• Not the Git network/escalation path (run 3 — no network operation attempted at all).
• Not security-adjacent vocabulary in the material being read. Run 4 read a fault-injection test

harness containing SIGKILL, RLIMIT_FSIZE, malformed-input probes and crash-recovery cases
straight through without incident, and flagged much later while emitting ordinary Rust.

• Not the prompt's phrasing.

What holds across all four

The flag fires during final response composition, never on a tool call. In every run it lands
5–7 lines from the end of the transcript, after the last command completed, with 234 / 1,078 / 443 /
976 lines of generated output in between. Every tool call succeeds. Token counts are not monotonic
(58k to 153k), and the content type at the flag point differs each time — JSON, Rust source, a
plain-text table, Rust test code.

I do not have a positive explanation, and I would rather report the eliminations than offer a third
theory. Three variables tested and excluded may still be useful to whoever can see the
classification decision from the inside.

The practical cost

Run 4 lost 153k tokens of completed analysis because the final message could not be emitted. It was
also terminated mid-edit, leaving 105 uncommitted lines in a working file — recoverable here because
the work was in a disposable worktree, but a plain codex exec user editing their own repository
would be left with a partially applied change and an error message that does not mention it.

That sharpens one of the expected-behaviour items from my previous comment: a classification refusal
on the final response should not discard the turn, and ideally should not leave the workspace
mid-edit without saying so.