Windows app: authenticated GCS download blocked by client, followed by auto-review denial of diagnostic lookup

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

26.908.9136.0 (OpenAI.Codex Windows package metadata; About-dialog version not separately checked)

What subscription do you have?

Not provided in this public report.

What platform is your computer?

Windows, Codex desktop app with the in-app browser. Exact Windows build not collected.

What issue are you seeing?

A user-authorized, read-only workflow for existing JSON results in a user-owned private Google Cloud Storage project is blocked in the Codex Windows app. The user explicitly approved reading and downloading the existing results into the local workspace through the signed-in in-app browser. This did not authorize new generation, external sharing, permission changes, or production writes.

Two distinct failures were observed; their common cause has NOT been established:

1. The normal Google Cloud object management page showed signed-in access and metadata for a private JSON object of approximately 6.3 KB. Navigation to its normal authenticated download link returned net::ERR_BLOCKED_BY_CLIENT. No file body was confirmed received.
2. A subsequent lookup of supported browser file-receiving capabilities was rejected by automatic review as potentially circumventing the previous denial. The response began: This action was rejected due to unacceptable risk. The reason said the capability lookup after the blocked private GCS access could be a follow-up step that bypasses the earlier security refusal.

The agent stopped access attempts after this denial; no alternate API, browser, Cloud Shell route, credential extraction, or security-setting change was used. Public OpenAI documentation could subsequently be opened normally in the same in-app browser.

Please help diagnose the download failure and the supported recovery/re-review path for this narrowly authorized read-only operation. This is not a request to disable automatic review or grant unrestricted access.

What steps can reproduce the bug?

Historical sequence from the affected session (not a fresh reproduction against private data):

1. Use the Windows Codex desktop app with in-app browser control enabled, signed in to Google Cloud, and a user-owned private JSON object accessible through its ordinary management page.
2. Ask the agent to read/download the existing JSON for local validation only, with explicit user approval and no sharing, generation, permission changes, or production writes.
3. Attempt the ordinary authenticated download. The browser returned net::ERR_BLOCKED_BY_CLIENT, with no confirmed file receipt.
4. Ask what supported file-receiving functionality is available. Automatic review rejected the capability lookup as a possible follow-up to bypass the earlier refusal.

Related explicit denial timestamps: 2026-09-17 12:58:05 UTC (authenticated-link navigation) and 13:08:45 UTC (capability lookup). These are denial timestamps, not a claim about the exact time of the separate browser error.

The user later entered /approve in chat, but the session only showed a user message; there was no confirmation that an app-level reapproval command executed. No further blocked-data access was attempted to reproduce this report.

What is the expected behavior?

The app should provide a clear, supported way to determine why the authenticated download is blocked and whether the specific read-only action can be formally re-reviewed after explicit user approval. If it remains disallowed, the reason and supported next step should be clear. A diagnostic capability lookup that does not retry the protected-data request should either be supported or explain its own restriction. Browser download errors and automatic-review refusals should be distinguishable. Security protections should remain enabled.

Additional information

Privacy: no object contents, bucket/project identifiers, signed URLs, cookies, tokens, API keys, private local paths, full conversation, or raw logs are included. No screenshots or files are attached. Any additional sensitive diagnostics would require separate review and consent.

The user-provided settings screenshot showed in-app browser control enabled. The agent had suggested a site allow/block list, but could not verify such a control in this installed UI; that advice was withdrawn. Do not interpret this report as establishing Google IAM failure, an expired login, an ad blocker, or an organization policy as the cause.

This report was prepared and submitted with the user's explicit approval for public GitHub reporting. A focused search for is:issue "ERR_BLOCKED_BY_CLIENT" GCS returned no existing open or closed issues.

Start with the Windows desktop app's in-app browser flow and examine the reported authenticated GCS download and automatic-review denial as separate events. Use the reproduction sequence and denial timestamps to determine whether supported diagnostics or re-review guidance exists; done means the failure causes and supported next steps are clearly distinguished.