[macOS][Built-in Browser] role, DOM, and coordinate clicks do not activate shadow-DOM native button

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

Version 26.810.52044 (build 6662)

What subscription do you have?

Paid ChatGPT plan (exact tier is not exposed to the Codex task)

What platform is your computer?

macOS 26.6.1, Apple Silicon (arm64)

What issue are you seeing?

Codex Desktop's built-in Browser can resolve a visible, enabled native <button> inside an open shadow root by accessible role and name, but none of its activation transports actually activate it.

In an authenticated local Taproot form using @taprootio/espalier@2.15.1:

• getByRole("button", { name: "Create credential", exact: true }) resolves exactly one element and reports it visible and enabled.
• The built-in Browser's role-located .click() returns without error, but the application handler does not run.
• .press("Enter") also returns without error and does not run the handler.
• DOM CUA exposes the real inner <button type="button"> (not only the <esp-button> host); clicking its node id does not run the handler.
• A coordinate CUA click also has no effect.
• Role/name-driven textboxes and comboboxes in the same form work correctly.

This is not an unsupported host-element .click() call. The role locator resolves the native button inside the open shadow root, and DOM CUA separately exposes that same native button.

The component's public contract is a composed clicked event emitted exactly once from native activation. The same component and interaction pass with pinned Playwright driving real Chrome, for both role-located pointer click and Enter:

• Source/release: @taprootio/espalier@2.15.1
• Public implementation/fixture commit: taprootio/taproot-controls@c47cf93
• Fixture: __tests__/button/esp-button-automation.browser.html
• Driver: __tests__/button/esp-button-automation.driver.js
• Contract guide: docs/guides/browser-automation.md

This isolates the failure to the Codex built-in Browser input transport rather than the component's activation behavior.

Related but distinct: #36621 reports a final form action failing on Windows and in both Browser surfaces. This report is macOS, reproducible against a minimal open-shadow-root web component, and its real-Chrome fixture passes.

Bundled Codex CLI: 0.148.0-alpha.9
Built-in Browser plugin: 26.810.52044
Model: gpt-5.6-sol, reasoning effort xhigh

What steps can reproduce the bug?

A public minimal fixture is available in the repository above:

1. Check out taprootio/taproot-controls at c47cf93.
2. Install its pinned dependencies and build the source payload.
3. Serve the repository root over localhost.
4. Open /__tests__/button/esp-button-automation.browser.html in the Codex built-in Browser.
5. Confirm getByRole("button", { name: "Save draft" }) resolves one visible, enabled button.
6. Activate it using the built-in Browser role click.
7. Inspect window.__espEvents; it remains empty.
8. Repeat with Enter, the DOM-CUA native button node, and a coordinate click; the event remains absent.
9. Run the repository's pinned real-Chrome fixture for comparison:

bun run test:browser -- --only "button semantic automation"
It records exactly one clicked event for click and exactly one for Enter.

The original application reproduction uses the same component on a local authenticated form. No credentials, capability values, or private URLs are included here.

What is the expected behavior?

A semantic click or Enter on the visible, enabled native button should travel through the browser's real input pipeline and activate it exactly once, causing the component's composed clicked event and application handler to run.

The Browser API should not report successful completion when no activation was delivered. If the transport cannot activate the target, it should return a clear error rather than silently doing nothing.

Additional information

Text input and combobox automation began working after upgrading from Espalier 2.14.0 to 2.15.1, confirming that semantic role/name discovery and other trusted input paths are functioning. Button activation remains the isolated failure.

No secrets, credentials, account identifiers, or private application data are included.