[Windows Computer Use] Danea Easyfatt VCL TfrmMain window is visible in Win32 but not enumerated by list_windows

Related: #27747, #27287, #27464

Windows Computer Use does not enumerate Danea Easyfatt real VCL main window

Summary

Windows Computer Use bootstrap works and can enumerate/control Microsoft Word, but it does not enumerate the real visible Danea Easyfatt window.

Danea Easyfatt exposes a zero-size TApplication top-level window as the process MainWindowHandle, while the actual user-facing window is a separate visible TfrmMain top-level window. Computer Use appears to return no windows for Danea and rejects the valid TfrmMain handle when passed directly to get_window.

Environment

• Product: Codex Desktop Windows Store app
• Codex app path/build observed: OpenAI.Codex_26.609.3341.0_x64__2p2nqsd0c76g0
• Computer Use plugin: openai-bundled computer-use 26.609.30741
• @oai/sky: 0.4.10
• Runtime: cua_node\789504f803e82e2b
• OS: Microsoft Windows 11 Pro 10.0.26200, build 26200, 64-bit
• Target app: Danea Easyfatt Professional 2026.59

Note: the known @oai/sky package export mismatch was locally worked around first by adding this export:

"./dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js": "./dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js"

After that workaround, Computer Use bootstrap and sky.list_apps() succeeded.

What works

Computer Use works against Microsoft Word on the same machine/session:

{
  "foundWord": true,
  "wordApp": {
    "id": "Microsoft.Office.WINWORD.EXE.15",
    "displayName": "Word",
    "isRunning": true,
    "windows": [
      {
        "id": 3803086,
        "app": "Microsoft.Office.WINWORD.EXE.15",
        "title": "Word"
      }
    ]
  },
  "windowsCount": 1,
  "wordWindows": [
    {
      "id": 3803086,
      "app": "process:C:\\Program Files\\Microsoft Office\\root\\Office16\\WINWORD.EXE",
      "title": "Word"
    }
  ]
}

get_window_state({ include_text: true, include_screenshot: true }) also succeeded for Word and returned a screenshot plus an accessibility tree.

What fails

With Danea Easyfatt open, visible, foreground, and maximized, Computer Use reports the app as running but returns no targetable windows:

{
  "appCount": 40,
  "appsWithWindows": 0,
  "listWindowsCount": 0,
  "easyfattApps": [
    {
      "id": "{7C5A40EF-A0FB-4BFC-874A-C0F2E0B9FA8E}\\Danea Easyfatt\\Easyfatt.exe",
      "displayName": "Danea Easyfatt",
      "isRunning": true,
      "windows": []
    }
  ],
  "matchingWindows": [],
  "allWindows": []
}

Passing the real TfrmMain handle directly to sky.get_window() also fails:

[
  {
    "ok": false,
    "input": {
      "id": 4196470,
      "app": "process:C:\\Program Files (x86)\\Danea Easyfatt\\Easyfatt.exe",
      "title": " Danea Easyfatt Professional  2026.59  -  [company]"
    },
    "error": "Error: window id 4196470 was not found. Current windows: []"
  },
  {
    "ok": false,
    "input": {
      "id": 4196470,
      "app": "{7C5A40EF-A0FB-4BFC-874A-C0F2E0B9FA8E}\\Danea Easyfatt\\Easyfatt.exe",
      "title": " Danea Easyfatt Professional  2026.59  -  [company]"
    },
    "error": "Error: window id 4196470 was not found. Current windows: []"
  },
  {
    "ok": false,
    "input": {
      "id": 4196470,
      "app": "Easyfatt.exe",
      "title": " Danea Easyfatt Professional  2026.59  -  [company]"
    },
    "error": "Error: window id 4196470 was not found. Current windows: []"
  }
]

Win32 evidence

Windows itself sees the real visible Danea window.

Foreground window after moving Danea to the main/right monitor and maximizing:

Handle=4196470
Pid=8888
Class=TfrmMain
Title= Danea Easyfatt Professional  2026.59  -  [company]
Rect=-8,-8,1928,1040 (1936x1048)

Get-Process Easyfatt reports the process MainWindowHandle as the zero-size TApplication window:

ProcessName      : Easyfatt
Id               : 8888
MainWindowTitle  : Danea Easyfatt
MainWindowHandle : 3342794

Enumerating all top-level windows owned by Easyfatt.exe shows the issue:

Handle    : 4196470
Visible   : True
Minimized : False
Width     : 1589
Height    : 824
Rect      : 227,94,1816,918 (1589x824)
ClassName : TfrmMain
Title     :  Danea Easyfatt Professional  2026.59  -  [company]

Handle    : 3342794
Visible   : True
Minimized : False
Width     : 0
Height    : 0
Rect      : 960,540,960,540 (0x0)
ClassName : TApplication
Title     : Danea Easyfatt

After maximizing on the main/right monitor, the real foreground TfrmMain was:

Class=TfrmMain
Rect=-8,-8,1928,1040 (1936x1048)

So the app is not minimized, not hidden, and not running elevated. The relevant processes were all at Medium integrity:

Codex              Medium
codex-computer-use Medium
node_repl          Medium
Easyfatt           Medium

Native helper status

The Computer Use helper was running:

codex-computer-use.exe --parent-pid 23504

The configured native pipe existed:

\\.\pipe\codex-computer-use-69719428-2752-4481-9ce6-adb472da77d5

Reproduction steps

1. Start Codex Desktop on Windows.
2. Ensure Computer Use plugin 26.609.30741 is enabled.
3. Apply the temporary @oai/sky export workaround if the ERR_PACKAGE_PATH_NOT_EXPORTED issue is present.
4. Open Danea Easyfatt Professional 2026.59.
5. Put Danea in the foreground and maximize it on the main/right monitor.
6. Run Computer Use bootstrap and sky.list_apps() / sky.list_windows().
7. Observe that Danea is isRunning: true but has windows: [], while sky.list_windows() returns [].
8. Enumerate Win32 top-level windows for Easyfatt.exe; observe visible TfrmMain with nonzero dimensions.
9. Try sky.get_window({ id: <TfrmMain handle>, app: ... }); it fails with Current windows: [].

Expected behavior

Computer Use should enumerate the visible, non-minimized TfrmMain top-level window owned by Easyfatt.exe, even though the process MainWindowHandle / TApplication window is zero-size.

Actual behavior

Computer Use either reports no windows globally or reports no windows for Danea. It does not include the real TfrmMain window in list_windows() or in the Danea app's windows array, and get_window() rejects the valid Win32 handle.

Hypothesis

The Windows Computer Use native helper may be filtering by the process main window or by a window selection rule that excludes the real VCL/Delphi form (TfrmMain) when the app's TApplication window is visible but 0x0.

The durable fix likely needs to be in the native Windows window enumeration layer: when an app has a zero-size owner/application window, continue enumerating visible nonzero top-level windows for the same process and expose those as targetable Computer Use windows.