macOS: drag tool executes without error but performs no actual drag (window move / text selection)

[yokoochen]

Bug: macOS drag tool executes without error but performs no actual drag (window move / text selection)

Environment:

• macOS 15.7.7 (arm64)
• open-computer-use 0.3.1 (npm, native darwin-arm64 runtime)
• Permissions granted: Accessibility + Screen Recording (confirmed via ocu doctor)
• Display: 4K 3840×2160 at 2x Retina (logical 1920×1080)

Steps to reproduce:

1. Window drag — move Calculator:

   ocu call drag --args '{"app":"com.apple.calculator","from_x":1076,"from_y":1090,"to_x":976,"to_y":1090}'
   

   The call returns success (isError: false + screenshot payload), but the window position does not change (verified via AppleScript position of window before/after). Tried both 1x (logical points) and 2x (pixel) coordinates.

2. Text selection drag — TextEdit:

   • Open a new TextEdit document, type "hello world drag test 12345"
   • Drag across the text line (from text start to the right)
   • Press Cmd+C → pbpaste returns empty (no text was selected)

Expected: drag should move windows / select text like a real mouse drag.

Actual: the MCP tool posts the mouse events without error, but macOS does not register them as a real drag gesture. Neither window dragging (window server) nor in-app text selection recognizes the synthetic drag.

Notes:

• click, press_key, set_value, scroll, list_apps, get_app_state all work correctly on this machine — only drag is affected.
• Same behavior via the MCP server and via ocu call drag CLI directly.
• Happy to provide screenshots or run any additional diagnostics on request.

[yokoochen]

Additional data point: I also tested the Qwen fork (@qwen-code/open-computer-use 0.2.3) on the same machine — same behavior: the drag call executes successfully (isError: false) but the window does not move (verified via AppleScript position before/after). Both runtimes share the same drag implementation, so this appears to be a systemic limitation of the synthetic drag on macOS rather than a regression in 0.3.1.

Note: when running the Qwen fork via npx, its runtime reported accessibility=missing (different TCC responsible-process attribution), but running its native binary directly (child of the terminal that has Accessibility granted) resolves that. The drag behavior is identical either way.

[chidam333]

Yess