Computer Use can confirm the wrong dropdown option after fallback without validating the selected value

Summary

Computer Use can read a dropdown's options and current selected value, fail to select the requested option through accessibility, fall back to coordinate/keyboard interaction, and then confirm a different option without first validating the resulting selected value.

This report uses the Parallels Desktop new-VM OS selector as a deterministic reproduction. The affected workflow happened to involve FreeBSD, but the issue is broader: the same failure pattern could affect dropdowns for accounts, permissions, destinations, visibility, or other consequential choices.

Environment

• Codex Desktop: 26.730.61639 (build 6234)
• Bundled Computer Use plugin: 1.0.1000621
• macOS: 26.6 (25G72), arm64
• Target application: Parallels Desktop 26.4.0 (57513)

Steps to reproduce

1. Open Parallels Desktop's new virtual machine wizard.
2. Choose to create an empty VM / continue without an installation source.
3. Continue to the operating-system selector.
4. Ask Computer Use to select Other Linux (その他の Linux).
5. Inspect the accessibility state.

Computer Use reports an AXComboBox whose current title is Windows 11, with an AXList containing 15 text children, including Other Linux.

1. Attempt semantic selection of the exposed Other Linux child.
2. Observe that the selected value does not change.
3. Attempt to set the combo value directly.
4. Observe that the combo is not settable.
5. Fall back to coordinate/keyboard interaction and press Return to accept the presumed selection.

Actual behavior

• The exposed Other Linux option can be read but cannot be selected through the normal Computer Use element action.
• Direct value assignment fails because the combo is not settable.
• Coordinate/keyboard fallback can select a different item. In this reproduction it selected macOS.
• Return then accepted that wrong value and advanced to the next wizard screen, which showed the VM name macOS (1).
• The wrong value was readable after the action, but it had not been validated before confirmation.
• The mismatch was detected immediately afterward and the workflow returned before pressing Create, so no VM was created.

With explicit user authorization, direct macOS Accessibility inspection confirmed:

• the control is exposed as AXComboBox;
• its options are exposed as AXStaticText children of an AXList;
• the Other Linux child advertises AXPress;
• AXPress, AXShowMenu, AX focus, and keyboard navigation did not change the combo's AXTitle.

This means the accessibility tree advertises an actionable option even though the action is effectively a no-op for this control.

Expected behavior

Computer Use should fail closed when a dropdown selection cannot be verified.

Specifically:

1. Selection and confirmation must be separate actions.
2. After any semantic, coordinate, or keyboard selection attempt, Computer Use should read the selected value again.
3. It should press OK, Return, Continue, Save, or any other confirmation control only when the selected value exactly matches the requested value.
4. If an accessibility option is visible but its advertised action does not change the control value, Computer Use should report that the control is unsupported instead of silently falling back through increasingly indirect input methods.
5. Fallback input should remain bound to the exact target window/sheet; foreground-window changes must not retarget the action.
6. A mismatched or unreadable selected value should stop the workflow and request manual intervention.

Why this matters

The individual Parallels/FreeBSD workflow is uncommon, but the failure class is general. Silent wrong-option confirmation can be consequential in dropdowns controlling permissions, publication scope, accounts, environments, storage locations, or destructive actions.

The important defect is not merely that one custom combo box is incompatible. It is that Computer Use can read enough state to detect the mismatch but may confirm before performing that validation.

Related issues

• #25788 — fallback input reached the macOS login password field and success was reported
• #36829 — Computer Use can follow foreground focus and act in another project window
• #21668 — wrong macOS Space/window targeting
• #35041 — foreground-visible success claimed before foreground acceptance

I searched open and closed issues in openai/codex for Computer Use dropdown, combobox, accessibility selection, wrong option, and selection verification reports. I found the related reports above but no issue covering this exact dropdown-selection-and-confirmation failure.