[Computer Use][Windows] Text input reactivates the ERP top-level window and causes MDI child edit controls to lose focus

[Computer Use][Windows] Text input reactivates the ERP top-level window and causes MDI child edit controls to lose focus

Issue type:

Computer Use regression — incorrect focus handling and input targeting on Windows

Environment:

Operating system: Windows

Application: Current version of the Codex desktop app

Target application: Legacy Windows MDI-based ERP system

Regression: Text input worked correctly in previous Codex versions. The problem appeared after a Codex update.

/feedback session ID: 01a01282-d132-7370-b27c-06ad23a5f634

Steps to reproduce:

Launch the ERP application.

Open the “Sales → Sales Order Management” MDI child window.

Click an editable field, such as the order number field.

Confirm that the caret is visible and that the accessibility tree identifies the field as a focused edit control.

Use Computer Use to type text or send keyboard input.

Expected behavior:

Keyboard input should be sent directly to the edit control that currently has focus inside the ERP child window. Computer Use should not reactivate or refocus another window before sending the keystrokes.

Actual behavior:

When a text-entry action is executed, Computer Use first activates the ERP top-level window. Focus then moves away from the edit control in the sales-order child window and returns to the main navigation tree or another parent-level container. As a result, the text is not entered into the field.

Observed window hierarchy and focus behavior:

Top-level window: wizardERP

MDI child window: W_SAL_C04_01 Sales Order Management

After clicking the order number field, focus is correctly placed on an edit control.

When the text-entry action begins, focus moves back to the top-level window’s navigation tree or parent container.

The requested text does not appear in the edit control.

When a drop-down menu or popup list is open, Computer Use may continue using the parent or child window’s coordinate system. This can cause the click to pass through the popup or land on an underlying control.

Regression information:

The ERP application itself has not been updated or modified. The same fields could be entered normally using older versions of Codex Computer Use. The failure started after a Codex desktop or Computer Use component update.

Suggested investigation and fix:

Allow the actual MDI child window handle to be selected as the input target.

Provide an input mode that preserves the current foreground window and keyboard focus.

Do not automatically activate the registered top-level window before sending text or keystrokes.

When a popup menu or drop-down list appears, refresh the active window hierarchy and coordinate system before clicking.

Verify that focus remains on the original edit control immediately before sending keyboard input. If focus has changed, report the failure instead of sending the input to another control.

Additional technical note:

This does not appear to be a case where the ERP field is read-only or unable to accept keyboard input. Manual keyboard input works normally after clicking the field. The failure occurs because the automation’s text-entry action changes the active window or focus immediately before sending the keystrokes.

Privacy note:

The attached diagnostic session may contain sensitive ERP credentials or private screen content. Please restrict access to authorized OpenAI personnel and avoid reproducing sensitive values in public issue comments.

No source file or test is named. Start by reproducing the issue in the Windows Computer Use text-entry path with the supplied feedback session, observing the ERP MDI child, edit control, foreground window, and focus before input. Done means text reaches the focused edit control without reactivating the top-level window, and popup coordinates are refreshed before clicking.