Hello Parallels team and community,
I want to control Windows applications in Parallels from an automation assistant running on my Mac, alongside Mac applications, using one Mac session. Recent testing found that clicks with an explicit 200 ms duration work, while clicks with the tool's default duration (not measured) can be ignored. We would like to understand the supported input timing and whether this is a known issue.
Environment:
- Parallels Desktop 20.4.2 (55999), Standard Edition
- macOS 27.0.1 (26A434), Apple silicon
- Windows 11 ARM
- Parallels Tools 20.4.2-55999 installed
- Two displays; the VM normally runs full screen on the second display
- Mac automation: OpenAI Computer Use and a separate AppleScript/System Events test
Current settings and preparation:
- The requesting Mac application's control permission was removed and re-added. An earlier macOS System Events permission error (1002) stopped recurring.
- Mouse is set to Don't optimize for games; keyboard remains Automatic. Windows has been restarted after the mouse-setting change.
- In the Full Screen settings, Optimize for games and Use all displays in full screen were already off; neither was changed in this test.
Verified results after the restart:
- Using OpenAI Computer Use coordinate clicks with durationMs: 200, we repeatedly opened Start, launched Notepad, opened a new Notepad tab, and opened a right-click context menu.
- In an A/B test at the same Notepad coordinate, a right-click using the tool's default duration (not measured) produced no visible context menu; a right-click with durationMs: 200 opened it. We cannot specify an exact minimum required duration.
- Ctrl+A with an explicit 200 ms duration followed by paste successfully entered the complete mixed Korean, English, numeric, and punctuation test string: "키키 한글 입력 시험 / ABC xyz 123 !@#". The final text was verified on screen.
- In a separate typeText test, the first screenshot showed only part of the text, but a later screenshot showed the complete 13-character string. This means the earlier partial screenshot alone was insufficient evidence of dropped characters; input or rendering may have still been in progress.
- A 70-line, 1,539-character paste also succeeded. A wheel-up call produced no visible movement, including in a later screenshot; Page Up held for 200 ms did move the document by one page. Wheel input remains unresolved.
- A 200 ms taskbar click launched Windows Chrome. We then used 200 ms clicks to follow an existing ALPS bookmark and an on-page navigation button to reach its login screen. No login was submitted and no business transaction was performed.
Minimal reproduction to investigate:
1. Open a normal Notepad document in Windows 11 ARM and bring the VM to the foreground.
2. Send a Mac-side synthetic right-click at a fixed coordinate in the document with the automation tool's default duration (not measured); observe whether a context menu opens.
3. At the same coordinate, repeat with an explicit 200 ms duration and compare the visible result.
These are successful basic interaction tests, not proof of complete workflow reliability. Dragging, cross-application focus changes between Mac and Windows, long-running stability, and the intended business application workflow have not yet been validated. Wheel input did not work in the limited test above. We also cannot attribute the improvement independently to the permission repair, mouse setting, or restart; the same-coordinate duration comparison is the clearest isolated finding so far.
Earlier AppleScript/System Events tests sometimes finished without an error but produced no visible guest response. OpenAI Computer Use also intermittently returned its own noWindowsAvailable error. We are not assuming that this tool error or the earlier macOS permission error is a Parallels defect, and the recent successful input tests used Computer Use, not a newly verified AppleScript path.
Could you clarify:
1. Is there a documented minimum mouse-button/key press duration or interval for Mac-side synthetic input into Windows 11 ARM? Is the difference between the tool's default-duration clicks and explicit 200 ms clicks a known issue or expected input-capture behavior?
2. Is there a relevant fix in 27.0.3 or a newer release? We understand the current Parallels/macOS combination is outside the compatibility matrix. Before purchasing an upgrade, we would like to verify this exact workflow through a supported trial or a documented fix.
3. What method and settings do you support for Mac-side automated clicks, right-clicks, dragging, scrolling, and Unicode text entry into a Windows guest? Please distinguish Standard from Pro requirements. Guest command execution through prlctl exec was unavailable with this Standard license.
4. Which minimal reproduction or diagnostic information would let you distinguish a Parallels input-timing issue from the automation tool's event generation or asynchronous screenshot timing?
Thank you.
I want to control Windows applications in Parallels from an automation assistant running on my Mac, alongside Mac applications, using one Mac session. Recent testing found that clicks with an explicit 200 ms duration work, while clicks with the tool's default duration (not measured) can be ignored. We would like to understand the supported input timing and whether this is a known issue.
Environment:
- Parallels Desktop 20.4.2 (55999), Standard Edition
- macOS 27.0.1 (26A434), Apple silicon
- Windows 11 ARM
- Parallels Tools 20.4.2-55999 installed
- Two displays; the VM normally runs full screen on the second display
- Mac automation: OpenAI Computer Use and a separate AppleScript/System Events test
Current settings and preparation:
- The requesting Mac application's control permission was removed and re-added. An earlier macOS System Events permission error (1002) stopped recurring.
- Mouse is set to Don't optimize for games; keyboard remains Automatic. Windows has been restarted after the mouse-setting change.
- In the Full Screen settings, Optimize for games and Use all displays in full screen were already off; neither was changed in this test.
Verified results after the restart:
- Using OpenAI Computer Use coordinate clicks with durationMs: 200, we repeatedly opened Start, launched Notepad, opened a new Notepad tab, and opened a right-click context menu.
- In an A/B test at the same Notepad coordinate, a right-click using the tool's default duration (not measured) produced no visible context menu; a right-click with durationMs: 200 opened it. We cannot specify an exact minimum required duration.
- Ctrl+A with an explicit 200 ms duration followed by paste successfully entered the complete mixed Korean, English, numeric, and punctuation test string: "키키 한글 입력 시험 / ABC xyz 123 !@#". The final text was verified on screen.
- In a separate typeText test, the first screenshot showed only part of the text, but a later screenshot showed the complete 13-character string. This means the earlier partial screenshot alone was insufficient evidence of dropped characters; input or rendering may have still been in progress.
- A 70-line, 1,539-character paste also succeeded. A wheel-up call produced no visible movement, including in a later screenshot; Page Up held for 200 ms did move the document by one page. Wheel input remains unresolved.
- A 200 ms taskbar click launched Windows Chrome. We then used 200 ms clicks to follow an existing ALPS bookmark and an on-page navigation button to reach its login screen. No login was submitted and no business transaction was performed.
Minimal reproduction to investigate:
1. Open a normal Notepad document in Windows 11 ARM and bring the VM to the foreground.
2. Send a Mac-side synthetic right-click at a fixed coordinate in the document with the automation tool's default duration (not measured); observe whether a context menu opens.
3. At the same coordinate, repeat with an explicit 200 ms duration and compare the visible result.
These are successful basic interaction tests, not proof of complete workflow reliability. Dragging, cross-application focus changes between Mac and Windows, long-running stability, and the intended business application workflow have not yet been validated. Wheel input did not work in the limited test above. We also cannot attribute the improvement independently to the permission repair, mouse setting, or restart; the same-coordinate duration comparison is the clearest isolated finding so far.
Earlier AppleScript/System Events tests sometimes finished without an error but produced no visible guest response. OpenAI Computer Use also intermittently returned its own noWindowsAvailable error. We are not assuming that this tool error or the earlier macOS permission error is a Parallels defect, and the recent successful input tests used Computer Use, not a newly verified AppleScript path.
Could you clarify:
1. Is there a documented minimum mouse-button/key press duration or interval for Mac-side synthetic input into Windows 11 ARM? Is the difference between the tool's default-duration clicks and explicit 200 ms clicks a known issue or expected input-capture behavior?
2. Is there a relevant fix in 27.0.3 or a newer release? We understand the current Parallels/macOS combination is outside the compatibility matrix. Before purchasing an upgrade, we would like to verify this exact workflow through a supported trial or a documented fix.
3. What method and settings do you support for Mac-side automated clicks, right-clicks, dragging, scrolling, and Unicode text entry into a Windows guest? Please distinguish Standard from Pro requirements. Guest command execution through prlctl exec was unavailable with this Standard license.
4. Which minimal reproduction or diagnostic information would let you distinguish a Parallels input-timing issue from the automation tool's event generation or asynchronous screenshot timing?
Thank you.