Browser Use cannot upload files because file chooser / setInputFiles is not exposed in Codex Desktop IAB

I face the same issue.
Would like for this feature to be made available.

I hit the same file-upload limitation in a real utility/account portal on macOS.

The flow required attaching a lease PDF through an older popup-style upload widget. In the Codex in-app Browser, clicking the browse/attachment control did not open a usable file picker, and drag-and-drop did not work either, so the required document could not be uploaded.

Using normal Google Chrome for the same portal flow worked: the file picker opened, the PDF uploaded successfully, and the request could be submitted.

So the practical issue is that Browser Use/IAB currently has no reliable way to attach local files to upload controls. That blocks common admin workflows where a PDF or image attachment is mandatory.

I originally filed this separately as #23187, then closed it after finding this issue.

This limitation is causing issues for our workflows because it means that many features cannot be tested by browser use. We have to resort to workarounds such as usign the chrome extension or using the agent-browser CLI for file uploads.

Still reproducible on Windows Codex Desktop with Browser plugin build 26.803.41515, even though the current Browser skill now exposes waitForEvent("filechooser") and PlaywrightFileChooser.setFiles(...).

Sanitized repro against a signed-in Microsoft Power Apps import dialog:

1. Open Import solution; Browser Use sees one real input[type="file"] plus a visible Browse button.
2. Start tab.playwright.waitForEvent("filechooser", { timeoutMs: 10000 }) before clicking.
3. Clicking the visible Browse button times out waiting for the chooser.
4. Repeating against locator('input[type="file"]').click({ force: true }) also times out (the runtime reported a 3-second chooser timeout despite the requested 10 seconds) and reset the browser-control session after the unhandled rejection.
5. The native picker, when invoked, belongs to the Codex/ChatGPT app window, so Windows Computer Use correctly refuses to automate that window. The task therefore still requires manual file selection.

No credentials or private file contents were involved. This blocks an otherwise fully automated release-validation flow: upload a locally built solution ZIP, import it, and verify the imported tools. So the newer chooser API is a good direction, but it has not resolved the original limitation for this common React/Power Apps upload surface.

Reproduced on the current Codex for Windows build:

• Codex app: 26.803.10989.0
• Browser plugin: 26.803.81509
• Windows 11 x64, build 26200
• Tested: 2026-08-13

This also fails with the currently documented file-chooser flow (not only with the unavailable locator.setInputFiles() API):

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

Actual result:

Timed out after 3000ms waiting for file chooser.

The chooser event never arrives, no attachment appears in the signed-in chatgpt.com composer, and manual upload is still required. This confirms that the newer waitForEvent("filechooser") + chooser.setFiles(...) path does not resolve the underlying IAB upload limitation on this Windows build.

Additive evidence: the exact restriction is baked into the bundled tool's own instructions, not just an absent API surface.

From the shipped plugin source (\plugins/cache/openai-bundled/browser/<version>/scripts/browser-service.mjs\, embedded "Handle file inputs and uploads" doc block):

"Do not look for locator.setInputFiles(...); uploads are exposed through the chooser object."

So the model is explicitly told not to reach for it even where it might otherwise exist in the underlying Playwright layer. Same reproduction signature as this issue, hit independently against chatgpt.com's composer (Add photos & files menu → hidden #upload-files input, multi-file, enabled, but no visible bounding box) from a Codex Desktop in-app browser session — chooser wait times out, no native picker, zero attachment.

One framing suggestion for the fix: gating setInputFiles behind the same operator-approved, single-session browser context the chooser flow already runs in (rather than exposing it unconditionally) would address the likely reason it's fenced off — an autonomous agent silently injecting files into an arbitrary untrusted page — while still unblocking the legitimate case (an already-approved automation attaching files to a hidden input in a tab the operator already opened).

I built a community Codex skill that standardizes the currently exposed chooser workflow where it works, verifies the result, and adds optional clipboard and ZIP fallbacks. It does not add the missing direct setInputFiles primitive, so unsupported custom controls can still require manual selection:

Codex File Bridge

I tested it in Codex Desktop’s in-app browser on macOS across several upload architectures:

• A conventional visible <input type="file"> followed by a multipart form submission. The file was selected, submitted, and displayed under its original basename.
• A hidden file input triggered by a visible JavaScript button. The button emitted the chooser event, chooser.setFiles(...) populated the hidden input, and the page received the original filename, MIME type, and byte size.
• A custom drop-zone/button wrapper around a multiple-capable file input. The chooser opened through the custom control, and the page displayed an attachment card containing the exact basename and size before submission.
• A server pipeline that renames files after upload. The upload succeeded, the server added a timestamp prefix, and the skill detected and reported the site-visible name instead of incorrectly claiming that the original basename was preserved.
• A standard input that exposed only a sanitized C:\\fakepath\\<filename> value while its inspected FileList appeared empty. The skill correctly treated that as evidence of selection, not proof of server receipt. The site’s blocking JavaScript result dialog later stalled Browser Use, which remains documented as a partial result rather than a successful submission.

The public test targets included DLP Test, The Internet File Uploader, Expand Testing, and WebDriver University.

The primary workflow is:

1. Inspect the target field, including accept, multiple, and visible size or type restrictions.
2. Start waitForEvent("filechooser") before clicking either the actual input or its associated visible control.
3. Supply absolute paths through chooser.setFiles(...).
4. Verify observable evidence such as filenames, attachment cards, sizes, previews, progress, or server confirmation.
5. Report file selection, server receipt, and surrounding form submission as separate states.

If no chooser event arrives, the skill inspects the page before retrying. When the destination visibly supports pasted attachments, it can use a site-specific clipboard fallback. If the field accepts ZIP files, it can also create a safe bundle that preserves inner filenames and relative paths. If the page supports neither chooser upload nor attachment paste, the skill stops rather than pretending it bypassed the missing setInputFiles primitive.

For the specific case of attaching files to a ChatGPT Pro composer, use the dedicated ChatGPT Clipboard Upload skill. That workflow bypasses the chooser through clipboard attachments, reads the UUID-derived name ChatGPT assigns, and supplies a generated-name → original-name manifest. It also offers a ZIP fallback that preserves filenames inside the archive.

Bug reports are welcome in the Codex File Bridge issue tracker.