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

Start by reproducing the failure in Codex desktop on Windows using a trusted repository, workspace-write, restricted sandbox networking, automatic approval review, and the existing GitHub origin. Compare sandboxed and escalated git fetch or git push requests, including the approval UI and Trusted Access message. Done means the UI distinguishes sandbox/network approval from cybersecurity classification and provides a clear, narrowly scoped authorization for the requested operation.

What version of the Codex App are you using (From “About Codex” dialog)?

Current Codex desktop release as of 2026-07-22. The exact build was not captured before filing.

What subscription do you have?

Personal account (not a managed Business or Enterprise tenant).

What platform is your computer?

Microsoft Windows x64.

What issue are you seeing?

Routine GitHub operations in a trusted local repository repeatedly cross the automatic-review boundary and can produce an opaque block:

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.

The task was ordinary validation/documentation work. It explicitly excluded security auditing and security tooling. The requested external actions were normal git fetch and git push operations to the repository's existing GitHub remote, explicitly requested and repeatedly confirmed by the user.

Relevant runtime configuration:

• Codex desktop on Windows
• sandbox_mode = "workspace-write"
• automatic approval reviewer enabled
• network access restricted in the workspace sandbox
• trusted local repository
• existing HTTPS GitHub remote
• Git command prefixes previously approved

The first sandboxed Git network command fails because network access is disabled. Retrying the same command with an escalation invokes automatic review. In this failure mode, the UI presents Trusted Access/cybersecurity messaging or hides the relevant content entirely. This makes a sandbox/network permission boundary look like a cybersecurity-policy rejection.

The false classification is especially confusing because the linked Trusted Access application is for managed security programs and is not applicable to a personal user doing non-security work.

This also consumes additional model usage: the agent retries, explains the boundary, re-evaluates the task, and may still fail to perform an operation the user explicitly authorized.

What steps can reproduce the bug?

1. Open a trusted local Git repository in Codex desktop on Windows.
2. Use workspace-write with automatic approval review and restricted sandbox network access.
3. Configure the repository with its normal existing GitHub origin.
4. Ask Codex to fetch a known branch or push the current branch.
5. Observe the sandboxed command fail because network access is disabled.
6. Have the agent retry the exact git fetch or git push with the required escalation.
7. Observe automatic-review / Trusted Access UI. In affected turns, the result is replaced with “This content can't be shown” and cybersecurity guidance despite the task being non-security work.
8. Repeat after explicitly authorizing the exact Git operation; the workflow may cross the same boundary again.

What is the expected behavior?

• A normal fetch/push to the existing remote of a trusted repository should be permitted after one explicit, narrowly scoped authorization.
• The authorization should persist for the task/session, or Codex should expose an actionable allowlist for that exact Git remote and operation.
• Approval UI should always show the exact command, destination, requested permission, and reason it crossed the sandbox boundary.
• “This content can't be shown” should not hide the information necessary to understand or approve a request.
• The UI must distinguish sandbox/network approval from Codex Security, cybersecurity classification, and Trusted Access.
• Identical, previously approved low-risk Git operations should not repeatedly consume model usage for automatic review.
• Personal-account users should not be directed to an inapplicable managed-business Trusted Access program for ordinary repository operations.

Additional information

This overlaps with #32007 (authorized Git push denied by auto-review) and #33130 (false cybersecurity “content can't be shown” message), but the combined desktop failure is distinct: a routine sandboxed Git network escalation is surfaced as an opaque cybersecurity/Trusted Access block.

The underlying configuration concepts—project trust, command-prefix approval, and sandbox network permission—appear to be separate, but the product UI does not explain that distinction or provide a durable, narrowly scoped GitHub-network authorization. No repository contents, credentials, or private organization data are included in this report.