›_ Codex Issues
Codex Issues / #36335

Windows Computer Use rejects Blender window with identical owner and can capture it under Explorer

Open 💬 3 comments Opened Jul 31, 2026 by barrettpk1-arch

Summary

On Windows, Computer Use enumerates a Blender window correctly but get_window, activate_window, and get_window_state reject it with a contradictory ownership error:

window id <HWND> no longer belongs to blender.4.5; current owner is blender.4.5

In one isolation test, Computer Use accepted a window listed as File Explorer but the screenshot contained Blender instead. This suggests the Window2 HWND-to-app ownership mapping can become cross-wired.

Environment

  • Windows 11 Pro 25H2, build 26200.8875
  • Codex desktop package: OpenAI.CodexBeta_26.727.4816.0_x64
  • Computer Use plugin: 26.727.40816
  • Blender: 4.5.12 LTS
  • Blender app identifier returned by list_apps / list_windows: blender.4.5

Minimal reproduction

  1. Install and enable the bundled Computer Use plugin.
  2. Approve only the canonical Blender app ID blender.4.5.
  3. Launch a fresh Blender 4.5.12 process with one visible window.
  4. Call list_windows(); it returns exactly one Blender window:

``json
{"app":"blender.4.5","id":4918426,"title":"<blend file> - Blender 4.5.12 LTS"}
``

  1. Rehydrate the returned object:

``js
const w = await sky.get_window({ id: returned.id, app: returned.app });
``

  1. The call fails:

``
window id 4918426 no longer belongs to blender.4.5; current owner is blender.4.5
``

Passing only the ID to get_window({ id }) returns a window object, but subsequent capture still fails with the same message.

Troubleshooting completed

  • Fully quit and restarted Codex.
  • Uninstalled and reinstalled Computer Use.
  • Enabled its server and skill toggles.
  • Restarted only the codex-computer-use helper.
  • Launched fresh Blender processes and fresh HWNDs.
  • Removed duplicate process-path approvals, leaving only blender.4.5.
  • Tested with the Blender splash disabled.
  • Confirmed the plugin cache matches the bundled marketplace copy.
  • Confirmed unrelated File Explorer capture succeeds through the same helper.

None changed the Blender failure.

Wrong-window isolation evidence

A window returned as:

{"app":"process:C:\\Windows\\explorer.exe","id":657810,"title":"<folder> - File Explorer"}

was accepted by get_window_state, but the resulting screenshot showed the Blender viewport and splash. This is a privacy/safety concern in addition to preventing Blender control.

Expected behavior

A fresh window object returned by list_windows should bind and capture when the reported owner and current owner are both blender.4.5. Computer Use must not capture a different application's content under an Explorer window identity.

View original on GitHub ↗

3 Comments

weiwei187242 · 25 days ago

Additional confirmed reproduction with WeChat DevTools (an NW.js application).

Environment

  • Windows 11 Pro 25H2, build 26200.8875
  • Codex desktop package: OpenAI.Codex_26.727.6591.0_x64
  • Computer Use plugin: 26.727.51351
  • @oai/sky: 0.6.2
  • WeChat DevTools: Stable v2.01.2510290
  • App identifier returned by both list_apps() and list_windows():

nwjs._nwjs_mbeehgnikfbgjh.80d774828fb0.Default

Reproduction

list_apps() consistently returns the WeChat DevTools windows, including this unique window:

{
  "app": "nwjs._nwjs_mbeehgnikfbgjh.80d774828fb0.Default",
  "id": 17959512,
  "title": "WeChat DevTools Stable v2.01.2510290"
}

Rehydrating that exact returned object fails:

const w = await sky.get_window({
  id: returned.id,
  app: returned.app,
});
window id 17959512 no longer belongs to nwjs._nwjs_mbeehgnikfbgjh.80d774828fb0.Default; current owner is nwjs._nwjs_mbeehgnikfbgjh.80d774828fb0.Default

The reported expected owner and current owner are identical, as in the Blender reproduction above.

Troubleshooting completed

  • Refreshed list_apps() and retried with the newly returned object.
  • Refreshed through list_windows() and confirmed the same HWND/app mapping.
  • Reset the JavaScript runtime, reinitialized Computer Use, and retried.
  • Confirmed the Computer Use helper, WeChat DevTools, and Codex all run in Windows session 1 at Medium integrity.
  • Confirmed the same helper can bind and capture an unrelated 7-Zip window.

The WeChat DevTools window remains unbindable after these checks. This suggests the contradictory ownership validation is not Blender-specific and also affects NW.js app identifiers.

piaoxiangbeifang123 · 24 days ago

Hi, I'm experiencing what appears to be the same issue with Codex Computer Use on Windows, but with AdsPower's SunBrowser.

The error is:

window id 70378 no longer belongs to SunBrowser; current owner is SunBrowser

The expected owner and current owner are displayed as exactly the same application, but Codex still rejects the window when trying to read or interact with its contents.

Restarting Codex, AdsPower, and SunBrowser did not resolve the issue.

Has this been fixed in a newer Codex or Computer Use build, or is there currently a known workaround? I can provide my Windows version, Codex desktop version, Computer Use plugin version, and additional logs if needed.

Thanks!

1063716500-sketch · 22 days ago

Additional reproduction indicating this may be a system-wide ownership-validation failure rather than an application-specific compatibility issue.

Environment

  • Windows 10 Pro 22H2, build 19045.6466
  • Desktop app: 26.730.8199.0 (Microsoft Store reported no newer update)
  • Computer Use plugin: 26.730.61639
  • @oai/sky: 0.6.2
  • Native helper: 0.1.0

Scope

The same contradictory ownership error reproduces across multiple unrelated applications on the same installation, including:

  • ChatGPT
  • Clash Verge
  • Feishu
  • Thunder
  • Adobe Illustrator
  • File Explorer

For each affected window, the expected owner and current owner printed in the error are identical:

window id <HWND> no longer belongs to process:<path>; current owner is process:<same path>

Additional validation

  • get_window({ id }) without an app value can return the correct window object.
  • get_window_state, activate_window, and calls that include the returned app identity fail ownership validation.
  • Windows GetWindowThreadProcessId confirms the HWND is valid and belongs to the process represented by that same executable path.
  • Fully restarting the desktop app and native helper did not change the result.
  • Rebuilding the app-catalog cache did not change the result.
  • Testing freshly enumerated HWNDs and canonical/alternate app identifiers did not change the result.
  • The Store update check reports the installed desktop build as current.

No screenshots, project files, local paths, or user content are attached to this report.

This appears to broaden the issue beyond Blender/NW.js/SunBrowser: on this Windows 10 installation, ownership validation rejects every tested application even when its own diagnostic output says both owners are identical.