Chrome plugin file upload setFiles fails with Not allowed and upload forms can hang

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

• #21560
• #20785

Powered by Codex Action

Additional repro detail: this is not limited to the authenticated Zoetis form.

I created a minimal local page served from http://127.0.0.1 with a plain file input:

<input id="receipt" name="receipt" type="file">

Using the Chrome plugin against that simple page:

const input = tab.playwright.locator('input[type="file"]');
const chooserPromise = tab.playwright.waitForEvent("filechooser", { timeoutMs: 10000 });
await input.click();
const chooser = await chooserPromise;
await chooser.setFiles(["/absolute/path/to/dummy-upload.txt"]);

Observed result:

{"code":-32000,"message":"Not allowed"}
fileChooser.setFiles failed

So there appear to be two related behaviors:

1. On a simple local page, Chrome plugin can open the file chooser but chooser.setFiles(...) fails with Not allowed.
2. On the authenticated invoice upload form, multiple follow-up DOM/CUA/file-upload calls hung until the runtime timed out/reset.

Environment details from the local checks:

• macOS
• Chrome 147.0.7727.138
• Codex Chrome Extension installed/enabled, version 1.1.4_0
• Native messaging host manifest exists and matches the expected extension origin
• Helper scripts succeed when run as node scripts/...

Confirming the same upload-timeout pattern on Windows and a different authenticated upload surface (observed July 10, 2026).

Environment

• Windows
• Codex Desktop: 26.707.3748.0
• Codex CLI: 0.144.0
• Chrome: 150.0.7871.101
• ChatGPT Chrome Extension: 1.2.27203.26575_0
• Site: authenticated https://sleek.design/dashboard

Reproduction

1. The Chrome plugin connects successfully and claims the already signed-in Sleek dashboard tab.
2. Initial screenshot and DOM inspection work.
3. Start waitForEvent("filechooser"), click the page's image-attachment control, and call setFiles(...) with five synthetic/demo-safe PNGs.
4. The chooser reports success.
5. The next domSnapshot() call hangs until timeout and resets the browser-control runtime.
6. Chrome remains visible but covered by a gray locked overlay, preventing normal user interaction.

The failure persisted after Chrome/Codex/Windows restarts and plugin reinstallation. Local extension and native-host checks passed. No credentials or private/customer data were uploaded.

This matches the core behavior reported here—normal authenticated navigation followed by upload-page bridge timeout—but also shows the issue on Windows, in newer Codex/extension versions, and with a post-timeout Chrome lock that does not reliably release user control. Related Windows bridge/uninstall report: #21670.

Confirming a second Windows failure mode on an authenticated HTTPS upload form (observed July 13, 2026).

Environment

• Windows NT 10.0.26200 x64
• Codex Desktop: 26.707.8168.0
• Chrome plugin used for the reproduction: 26.707.30751
• Chrome: 150.0.7871.115
• ChatGPT Chrome Extension: 1.2.27203.26575_0

Reproduction

1. The Chrome plugin connected, enumerated the existing signed-in tab, claimed it, and read its HTTPS URL and DOM successfully.
2. The page contained a normal file input and associated label:

``html
<label for="attachment">Add attachment</label>
<input id="attachment" type="file">
``

1. The documented chooser flow was attempted first against the input and then independently against the visible label:

``js
const chooserPromise = tab.playwright.waitForEvent("filechooser", { timeoutMs: 10000 });
await input.click({ force: true }); // the label click was tested separately
const chooser = await chooserPromise;
``

1. Both variants failed with:

``text
Timed out after 3000ms waiting for file chooser.
`
The observed 3-second timeout also ignored the requested timeoutMs: 10000`.

1. Chrome's profile state showed file URL access enabled (newAllowFileAccess: true). Extension and native-host health checks passed.
2. Raw CDP DOM.setFileInputFiles was then rejected by the browser client with:

``text
This method is not supported through raw CDP. Use tab.playwright.waitForEvent("filechooser") and chooser.setFiles(...) instead.
``

This leaves no working Chrome-only upload path: the supported chooser event never arrives, while the lower-level file-input command redirects back to the same failing chooser flow. The documented native-picker fallback is also blocked on this Windows setup by the separate browser URL-confidence issue tracked in #25271.

Expected behavior: the chooser event should fire and permit setFiles(...), or fail with a specific permission/capability error. The configured timeout should also be honored.

No credentials, private report content, or real user/customer data are included in this reproduction.

Follow-up from the same Windows machine (observed 2026-07-14): I can now distinguish the permission failure from a control-targeting failure, and I have a successful Chrome-only upload path.

Environment

• Windows NT 10.0.26200 x64
• Chrome plugin: 26.707.62119
• ChatGPT Chrome Extension enabled in the Default profile
• Extension/native-host health checks pass
• Allow access to file URLs was already enabled

Successful isolation test

A plain local <input type="file"> served from http://127.0.0.1 worked end to end:

const chooserPromise = tab.playwright.waitForEvent("filechooser", { timeoutMs: 10000 });
await input.click();
const chooser = await chooserPromise;
await chooser.setFiles(["C:/absolute/path/to/test.zip"], { timeoutMs: 15000 });

The page observed the expected file name, size and MIME type, with no browser warnings/errors. This proves the extension permission and setFiles path were functional in the same Chrome session.

Authenticated HTTPS form

The failing form used a visually hidden file input and a visible associated label:

<label for="attachment">Add attachment</label>
<input id="attachment" type="file">

The input was technically display: block but opacity: 0 and approximately 0.09375 × 0.09375 CSS pixels. Waiting for filechooser and clicking the input had previously produced the chooser timeout. Using the visible associated label instead worked:

const chooserPromise = tab.playwright.waitForEvent("filechooser", { timeoutMs: 10000 });
await tab.playwright.locator('label[for="attachment"]').click();
const chooser = await chooserPromise;
await chooser.setFiles(["C:/absolute/path/to/test.zip"], { timeoutMs: 15000 });

Afterward the form set C:\\fakepath\\test.zip, marked the field changed, and appended the next empty attachment input. No console warnings/errors were recorded.

Product implication

In this failure mode, file-URL permission is not the root cause. The current troubleshooting collapses “chooser never opened” and “setFiles was denied” into the same permission advice. A useful fix would be to:

1. distinguish chooser-event timeout from setFiles permission/capability failure;
2. automatically prefer a visible label[for] when the underlying file input is effectively non-interactable;
3. honor the requested timeout and return a bounded actionable error instead of resetting the runtime.

No credentials, private report content, target name, or customer data are included here.