[Windows][Computer Use] Accessibility monitor reads unrelated foreground app and can hang it via UIA BuildCache

Summary

On Windows, the bundled Computer Use native helper appears able to perform a UI Automation cache read against the current foreground window even when that application is unrelated to the requested target application.

In the observed case, the Codex task was working with Chrome, but the Computer Use helper's background accessibility monitor obtained the HWND of an already-running Everything window and called ElementFromHandleBuildCache against it.

Everything then became effectively hung/busy.

The user never requested Codex to inspect, search, activate, or control Everything.

Offline analysis of a captured process dump indicates that this was not caused by Codex launching Everything. Instead, codex-computer-use.exe followed an internal monitor path that obtains the current foreground window without carrying a specific target HWND.

This looks like a target/application-boundary problem in the Windows Computer Use accessibility monitor.

Environment

• Codex Desktop on Windows
• Bundled Computer Use / @oai/sky
• Native helper: codex-computer-use.exe
• Target application requested by the task: Chrome
• Unrelated affected application: Everything
• Everything was already running before the Computer Use helper started

Exact Codex/Computer Use build numbers were not captured in this diagnostic pass.

Observed timeline

Relevant timestamps from the captured run:

• Everything had already been running since approximately 08:52.
• 10:15:22.373 — the Chrome-related task called sky.list_apps().
• 10:15:23.291 — sky.list_apps() returned.
• Startup of codex-computer-use.exe corresponds to this stage.
• 10:15:34.672 — the task later called Chrome get_window_state(..., include_text: true).

The important point is that the task was targeting Chrome. There was no explicit Everything operation.

Native dump evidence

Offline WinDbg/disassembly analysis of the saved codex-computer-use.exe dump found an accessibility-monitor path with approximately the following behavior:

monitor queue / message processing
        ↓
no concrete target window / state == -1
        ↓
internal branch
        ↓
GetForegroundWindow()
        ↓
Everything HWND
        ↓
ElementFromHandleBuildCache(...)
        ↓
UIA cache/tree read against Everything

In the captured monitor thread:

• the native frame still contained the Everything HWND (0x5516AA);
• relevant frame state values were 0xffffffffffffffff, consistent with the branch that does not carry a concrete target-window payload;
• an additional state value was 3, but its enum/type symbols are unavailable, so I am not claiming that 3 means focus-change, timer refresh, startup refresh, etc.;
• disassembly confirmed an internal path that reaches GetForegroundWindow();
• the resulting foreground HWND was Everything;
• the helper subsequently entered ElementFromHandleBuildCache.

The dump therefore provides evidence that the helper actually performed a UIA cache read against Everything.

What is proven vs. not yet proven

Supported by the captured dump

1. codex-computer-use.exe had an active background accessibility-monitor path.
2. That path can obtain the current foreground HWND without using a specific requested target HWND.
3. In this run, the HWND obtained by that path was the Everything window.
4. The helper performed ElementFromHandleBuildCache / UIA cache construction against that Everything HWND.
5. The user task itself was targeting Chrome, not Everything.
6. Everything was not launched by this task; it had been running substantially earlier.

Not yet determined

The dump does not contain enough historical event tracing to determine exactly what woke the monitor for the first read.

Possible sources still include:

• helper/startup initialization;
• an accessibility or foreground-window event;
• a periodic/timed monitor refresh;
• an internal queue message;
• another Computer Use initialization request.

I therefore do not want to claim which of those mechanisms triggered the first read without additional tracing.

Why this seems problematic

Application discovery and target control appear to be crossing two different scopes.

A task may explicitly target Chrome, but the helper's background accessibility monitor can independently do:

GetForegroundWindow()
→ build UIA cache for whichever application happens to be foreground

That means an unrelated desktop application can receive a potentially expensive accessibility-tree traversal merely because it was foreground at the wrong moment.

For applications with large, unusual, or slow UIA providers, this may cause significant latency or hangs.

It also appears inconsistent with the expectation that Computer Use inspection should remain scoped to the application/window selected for the task.

Expected behavior

Computer Use should not build a full UIA cache for an unrelated foreground application unless that application is explicitly part of the current Computer Use target/allowed scope.

For example:

target HWND/app = Chrome

monitor event
    ↓
GetForegroundWindow()
    ↓
if HWND/process is outside current authorized target set:
    do not perform ElementFromHandleBuildCache

Alternatively, monitor initialization/discovery should use lightweight HWND/process metadata and defer UIA tree/cache construction until a specific target application has been selected.

Actual behavior

A Chrome-related Computer Use task started the Windows helper.

The helper's background accessibility monitor independently obtained the current foreground window.

That window happened to be Everything.

The helper then performed a UIA ElementFromHandleBuildCache operation against Everything even though Everything was unrelated to the task.

Everything subsequently became unresponsive/busy.

Possible reproduction

A minimal reproduction to validate the suspected lifecycle would be:

1. Start Everything and leave its window in the foreground.
2. Start a fresh Codex Computer Use runtime.
3. Target Chrome or another unrelated application.
4. Execute only a low-risk discovery operation such as sky.list_apps().
5. Trace:
   • helper process creation;
   • monitor queue events;
   • GetForegroundWindow;
   • returned HWND;
   • ElementFromHandleBuildCache.
6. Check whether the foreground Everything HWND receives a UIA cache read before any explicit request to inspect Everything.

A useful timestamp sequence would be:

T0 helper process created
T1 list_apps request received
T2 monitor request/event queued
T3 GetForegroundWindow()
T4 unrelated HWND returned
T5 ElementFromHandleBuildCache(unrelated HWND)

If this happens during startup/discovery before a target-window inspection request, that would make the scope leak especially clear.

Suggested fix / invariant

The Windows accessibility monitor should maintain an explicit target/authorized HWND or process set.

A full UIA cache/tree read should only occur when the HWND belongs to that set.

If the monitor needs to observe foreground changes globally, it should first perform only lightweight HWND/PID checks and avoid constructing an accessibility cache for out-of-scope processes.

Related issue

• #36603 — Windows Computer Use can capture Codex instead of the selected Chrome target / transient dialog. This appears related at the target-boundary level, but the present report is specifically about a background accessibility monitor performing a heavy UIA read against an unrelated foreground application.

Additional note

No application code was modified during this investigation. The conclusions above come from saved dump/binary analysis rather than modifying Everything or forcing additional searches after the incident.

Start with the Windows Computer Use native helper lifecycle around sky.list_apps(), then trace the monitor path from GetForegroundWindow() to ElementFromHandleBuildCache. Use the proposed Chrome/Everything reproduction and capture the helper’s HWND and UIA calls. Done means an unrelated foreground application is not given a full UIA cache read, with target scoping verified by tracing or tests.