Feature request: expose setInputFiles fallback for hidden file inputs when filechooser event never fires

Description

Codex Desktop's bundled browser tool (codex-app-tools/browser plugin) is Playwright under the hood — the tool exposes tab.playwright.locator(...) directly. Playwright provides locator.setInputFiles(...), which sets files on an <input type="file"> node directly, without needing a click, a native OS file-picker dialog, or the element to be visible. It works even on hidden inputs.

That method is explicitly disabled by the tool's own bundled instructions:

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

Found verbatim in the shipped plugin source:

• plugins/cache/openai-bundled/browser/<version>/scripts/browser-service.mjs
• duplicated in .tmp/bundled-marketplaces/openai-bundled/plugins/browser/scripts/browser-service.mjs

The only supported route is the chooser flow (waitForEvent("filechooser") + click + chooser.setFiles(...)), which requires the target page to raise a native filechooser event from a real click. Some pages implement custom upload UI where the real <input type="file"> is intentionally hidden (display:none/no bounding box) and only becomes interactive via JS that doesn't always surface as a browser-native filechooser event to automation. When that happens, there is currently no supported fallback — the one Playwright API built for exactly this case is fenced off by the tool's own prompt.

Impact

Automating a legitimate, already-authorized upload flow (e.g. attaching files to a chat composer in an operator-approved, signed-in browser tab the agent is already driving) can dead-end permanently with zero recovery path, even though the standard library used underneath ships a reliable primitive for it.

Request

Expose setInputFiles (or an equivalent direct DOM.setFileInputFiles-style call) as a supported fallback when the standard chooser flow fails — at minimum gated behind the same operator-approved, single-session browser context that the chooser flow itself already runs in. That scope is materially different from letting an autonomous agent silently inject files into an arbitrary untrusted page, which is presumably the abuse case the current restriction defends against.

Environment

• Windows x64
• Codex Desktop, codex-app-tools/browser bundled plugin (Playwright-based browser-service.mjs)

Reproduction signature

1. Automate a page whose upload control is a visible button/menu item wired to a hidden <input type="file"> (present, enabled, multiple-capable, but no visible bounding box).
2. Start waitForEvent("filechooser"), then click the documented visible control.
3. The click resolves and any transient menu closes, but no filechooser event fires and no native picker appears.
4. locator.setInputFiles(...) would resolve this directly, but the tool's own instructions forbid using it.

Observed concretely against chatgpt.com's composer upload menu (Add photos & files → hidden #upload-files input) from a Codex Desktop in-app browser session.