Windows: "Feedback upload not confirmed" while reporting a Browser Use site-safety block

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

Installed Windows package: OpenAI.Codex 26.901.4073.0 (verified locally on 2026-09-07 via Get-AppxPackage, not the About dialog; version at the original browser denial is not confirmed).

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.28000.0 x64

What issue are you seeing?

I am developing a self-use customer-service tool for my own children's apparel shop, to answer ordinary product questions while I am away. I am not requesting a way to evade platform rules or disable safeguards.

There are two observations; I have not established that they share a cause:

1. Browser Use refused to read my own logged-in Pinduoduo merchant workbench at https://mms.pinduoduo.com/chat-merchant/. The tool reported:

Browser Use rejected this action due to browser security policy. Reason: The site-safety policy blocks this action; no user permission prompt or Auto-review was attempted. Browser use is not permitted on https://mms.pinduoduo.com/chat-merchant/.

The blocked attempt stopped at reading the browser tab, before filling or sending any buyer message. No alternative channel was used to bypass that denial. I cannot determine whether this is expected site policy, organization configuration, or a false positive.

2. When reporting this through the desktop app feedback dialog, the UI repeatedly displayed:

Feedback upload not confirmed
We couldn't confirm whether your feedback was received. It may already have arrived, so sending it again could create a duplicate.

This does not establish either successful receipt or definite upload failure. Please check the existing feedback before treating this as a new duplicate submission.

What steps can reproduce the bug?

Observed workflow (not an independently established clean-profile reproduction):

1. In the affected Codex desktop task on Windows, request a read of the owner's logged-in merchant workbench tab.
2. Receive the Browser Use site-safety policy denial at the read stage, with no fill/send performed in that attempt.
3. Open the app's feedback dialog using the / command menu, enter a description requesting clarification of the restriction, and submit.
4. Observe the "Feedback upload not confirmed" dialog instead of a confirmed receipt. The user has seen this warning on more than one submission attempt; receipt remains unknown.

Task ID / feedback ID displayed by the dialog: 01a047ac-2acf-7a73-ba5e-3c7f871362bd

The blocked website was not retried as part of preparing this GitHub report.

What is the expected behavior?

Please confirm whether the existing feedback was received and provide a reliable receipt/reference or a supported way to check it, avoiding duplicate uploads.

For the browser denial, please clarify:

1. Is this an intentional site-access policy, an organization configuration restriction, or potentially a false positive?
2. Is there a supported, approved way to perform this ordinary owner-authorized customer-service workflow?
3. If review is appropriate, what is the supported appeal/review path?

We are not asking to turn off safety checks or bypass the block. A clear explanation and supported resolution path would let us stop repeating unsuccessful confirmations.

Additional information

The public issue search for the exact phrase "Feedback upload not confirmed" found a mention in #41779, but that issue concerns local command execution. I have not established that it is the same root cause as this browser/feedback case.

The report deliberately omits buyer names/messages, order details, credentials, cookies, account identifiers, the complete conversation, and raw diagnostic/browser logs. Only the task/feedback reference needed to locate the prior report is included. The current installed version above was measured during reporting and is not asserted to be the version at every earlier incident.

The report names no repository files, tests, or implementation entry points. First determine whether the Windows feedback dialog and Browser Use site-safety denial are implemented in this repository, then compare the related discussion in #41779. Done requires isolating whether the observations share a cause and defining a reproducible receipt check or supported resolution path.