Windows Computer Use rejects Lightroom Classic window whose owner matches exactly

Resolved 💬 2 comments Opened Aug 10, 2026 by eliottmontero-create Closed Aug 10, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Computer Use successfully enumerates Adobe Lightroom Classic, but get_window / get_window_state rejects the returned window because it supposedly no longer belongs to Lightroom. The expected-owner process path and current-owner process path in the error are identical.

Exact error

window id 593030 no longer belongs to process:C:\Program Files\Adobe\Adobe Lightroom Classic\Lightroom.exe; current owner is process:C:\Program Files\Adobe\Adobe Lightroom Classic\Lightroom.exe

The window ID changes between Lightroom launches, but the contradictory ownership error is consistent.

Steps to reproduce

  1. Run the Codex desktop app on Windows with the elevated sandbox.
  2. Set windows.sandbox_private_desktop = false so Computer Use can enumerate the normal desktop.
  3. Open Adobe Lightroom Classic with a catalog loaded.
  4. Call sky.list_windows().
  5. Select the single returned window whose app is process:C:\Program Files\Adobe\Adobe Lightroom Classic\Lightroom.exe.
  6. Call sky.get_window({ id, app }), then sky.get_window_state({ window }).

Actual result

The helper rejects the valid returned window with the ownership error above even though both process identifiers are identical. Lightroom cannot be captured or controlled.

Expected result

The returned Lightroom window should remain bound to its owning process and get_window_state should capture it.

Troubleshooting already completed

  • Restarted Codex and Lightroom repeatedly.
  • Fixed an earlier lstat EPERM initialization failure by granting the elevated sandbox account read/execute access to the Codex local runtime.
  • Tested the preferred elevated sandbox.
  • Tested sandbox_private_desktop = false; enumeration then succeeds.
  • Tested the unelevated fallback; it failed separately with spawn EPERM.
  • Used Windows App Repair.
  • Renamed the cached cua_node runtime so Codex rebuilt it.
  • Performed a full Windows app reset.
  • Refreshed list_windows() and retried using only freshly returned window objects.

The Lightroom window-binding error persists after all of these steps.

Environment

  • Codex Windows app: 26.803.5235.0 x64
  • Computer Use plugin: 26.803.41515
  • @oai/sky: 0.6.2
  • Windows display version: 25H2
  • Windows build: 26200.8875
  • Adobe Lightroom Classic executable: C:\Program Files\Adobe\Adobe Lightroom Classic\Lightroom.exe
  • Sandbox: elevated
  • Private desktop: disabled for compatibility

Impact

This blocks direct Computer Use control of Lightroom Classic entirely. No Lightroom edits were attempted because visual capture could not be established.

Uploaded task reference: 019c0d37-d2b6-74c0-918f-0e64af9b6e14

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 18 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #37484
  • #37005
  • #37092

Powered by Codex Action

eliottmontero-create · 18 days ago

Closing as a duplicate of #37005. I added the Lightroom-specific reproduction details and environment there so this report remains linked as supporting evidence.