›_ Codex Issues
Codex Issues / #31505

Codex App does not indicate whether Trusted Access is missing or insufficient after verification

Open 💬 3 comments Opened Jul 8, 2026 by jason5545
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Codex App version:
26.623.141536 (4753)

Subscription:
ChatGPT Pro 5x

Platform:
Darwin 25.5.0 arm64 arm

What issue are you seeing?
Trusted Access verification appears to be completed successfully on the web, but the Codex App still shows a warning/block for the same type of task.

The web verification page shows that my identity has been verified and that Trusted Access is enabled. After that, I fully signed out of Codex, signed back in, quit the Codex App completely, and reopened it. The same type of Codex warning/block still appears.

The main issue is that Codex does not make it clear which state applies:

  • Trusted Access is not detected / not active for the current Codex session
  • Trusted Access is active, but this specific request still requires additional access, further review, or a higher trust level

Those are very different cases. From the user side, the web account state appears enabled, but Codex does not expose whether the current app session has actually picked up the entitlement.

Please treat this as a product/session-state and error-message clarity bug report, not an account support request. I have already contacted OpenAI Support separately.

I saw that there are other safety-check / Trusted Access reports in the issue tracker. This report is specifically about the missing distinction between "Trusted Access is not active for this Codex session" and "Trusted Access is active but insufficient for this request."

What steps can reproduce the bug?

  1. Complete Trusted Access verification through the web flow.
  2. Confirm that the web verification page shows Trusted Access as enabled.
  3. Fully sign out of the Codex App.
  4. Sign back in.
  5. Quit the Codex App completely and reopen it.
  6. Start a Codex task that previously triggered the Trusted Access warning/block.
  7. Observe that Codex still shows a warning/block, without clarifying whether Trusted Access is missing from the session or active but insufficient for the request.

Expected behavior:
After Trusted Access verification is complete and the user signs out/in, Codex should either:

  • pick up the updated Trusted Access entitlement, or
  • clearly say that Trusted Access is not active / not detected for the current Codex session, or
  • clearly say that Trusted Access is active but the request still requires additional access, further review, or a higher trust level.

Ideally, Codex should expose a visible account/access status somewhere in the app or CLI so users can verify whether Trusted Access is active for the current session.

Additional information:

  • OpenAI Support case: 11016613.
  • Screenshots showing the enabled web verification page and the Codex warning/block have already been attached to that support case.
  • Verification page was viewed in Helium.
  • Codex CLI installed locally: codex-cli 0.142.3.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #30271

Powered by Codex Action

jason5545 · 1 month ago

I reviewed #30271. It is related, but I do not think this issue is an exact duplicate.

#30271 is mainly about a legitimate reverse-engineering workflow being flagged as Cyber Abuse after cyber verification.

This issue is narrower: Codex does not distinguish between two different states after Trusted Access verification:

  1. Trusted Access is not active / not detected for the current Codex session
  2. Trusted Access is active, but the specific request still requires additional access, further review, or a higher trust level

That distinction matters because the user action and expected product behavior are different in each case.

jason5545 · 1 month ago

Update after testing the latest app build and inspecting the local Codex protocol/log output:

  • The issue still occurs in Codex App 26.707.41301 (5103).
  • It also occurred in 26.623.141536 (4753), so the behavior persists across app updates.
  • The failed turn was recorded as a structured backend failure with error.code = "cyber_policy". A second event reported type = "invalid_request" with the same cyber_policy code.
  • Neither response included a field indicating whether Trusted Access was present, missing, still syncing, or present but insufficient for that request.

The current app-server protocol does define more specific cyber-related types:

type ModelVerification = "trustedAccessForCyber";

type ModelVerificationNotification = {
  threadId: string;
  turnId: string;
  verifications: ModelVerification[];
};

type ModelRerouteReason = "highRiskCyberActivity";

However, the normal account/session surfaces do not expose the entitlement state:

  • account/read returns the account and authentication requirement, but no Trusted Access status.
  • model/list does not expose a Trusted Access status.
  • The affected failed turn contained the final cyber_policy error, but no persisted model/verification event that could clarify the state.

The packaged App maps codexErrorInfo === "cyberPolicy" to the generic cyber safety banner. As a result, the App shows the suggestion to apply for Trusted Access whenever it receives cyber_policy, even when the web verification page already reports Trusted Access as enabled.

This confirms the ambiguity described in the original report: from the client side, there is currently no way to distinguish:

  1. Trusted Access is missing or not synced.
  2. Trusted Access is active, but the request is still denied by policy.
  3. A different or additional access level is required.

A useful fix would be either to expose the current Trusted Access entitlement in the account/session state, or return a more specific machine-readable denial reason so the App can show the correct message.