[Bug / Feature Request] Windows App for macOS cannot reliably forward global keyboard shortcuts to remote Windows sessions

Jin Ye 0 Reputation points
2026-10-13T12:42:48.8766667+00:00

Summary

Windows App for macOS does not reliably forward keyboard shortcuts that conflict with macOS global hotkeys to a remote Windows session.

For example, when Raycast registers Left Option + Space as its activation shortcut, pressing this combination while a Windows App remote desktop session is focused activates Raycast on macOS instead of triggering Alt + Space in the remote Windows environment.

Other remote desktop applications, such as ToDesk, can provide more comprehensive keyboard shortcut forwarding, suggesting that this is not an unavoidable limitation of macOS.

Additionally, attempts to work around the conflict using Karabiner-Elements reveal a possible modifier-key forwarding issue in Windows App.

Environment

Local OS: macOS (Apple Silicon)

Remote OS: Windows

Remote desktop client: Microsoft Windows App for macOS

Keyboard customization: Karabiner-Elements

Global shortcut manager: Raycast

Raycast activation shortcut: Left Option + Space

Intended remote shortcut: Alt + Space (used to activate CmdPal)

Keyboard input mode: Scancode/Unicode mode not yet isolated as a test variable

Issue 1: Global shortcuts are intercepted by macOS instead of being forwarded

Steps to reproduce

Install Raycast on macOS.

Configure Raycast's activation shortcut as Left Option + Space.

Connect to a remote Windows machine using Windows App.

Focus the remote desktop session.

Press Left Option + Space.

Actual behavior

Raycast is activated locally on macOS.

The shortcut is not successfully forwarded to the remote Windows session, so CmdPal is not activated.

Expected behavior

Windows App should provide an option to prioritize remote keyboard shortcuts when the remote desktop session is focused.

When remote shortcut forwarding is enabled, pressing Left Option + Space should send the corresponding Alt + Space combination to the remote Windows session, without activating Raycast locally, where macOS permits interception.

Comparison with other remote desktop clients

Other remote desktop applications, including ToDesk, offer more comprehensive keyboard shortcut forwarding capabilities.

This suggests that Windows App could potentially improve its handling of global keyboard shortcuts rather than requiring users to disable or reconfigure their local keyboard shortcuts.

Issue 2: Possible modifier-key forwarding issue when using Karabiner-Elements

I performed additional experiments to investigate whether remapping the conflicting shortcut could work around the problem.

Experiments and observations

Experiment A: Remapping Left Option + Space to Right Option + Space

Configuration:

Raycast activation shortcut: Left Option + Space

Karabiner-Elements remapping for Windows App: Left Option + Space → Right Option + Space

Observed result:

Raycast does not activate.

The remote CmdPal also does not activate.

This suggests that avoiding the original global shortcut conflict is not sufficient to make the remapped shortcut work reliably.

Experiment B: Disable Windows App-specific remapping

Configuration:

Raycast remains enabled.

The Windows App-specific Karabiner remapping is disabled.

Observed result:

Raycast activates when the shortcut is pressed.

The remote CmdPal does not activate.

Experiment C: Completely quit Raycast

Configuration:

Raycast is completely closed.

The original Option + Space shortcut is used without the conflicting global hotkey.

Observed result:

The remote CmdPal activates successfully.

This suggests that the remote application and the basic shortcut-forwarding path can work when the local global shortcut conflict is removed.

Additional observation

While investigating the problem using the Windows On-Screen Keyboard, I noticed that the Alt modifier appeared to become released when Space was pressed.

This raises the possibility that modifier-key state is not always preserved correctly when Windows App receives remapped keyboard events.

However, this observation has not yet been verified against low-level Windows keyboard event logs.

Requested improvements

1. Add configurable remote keyboard capture

Please provide an option similar to:

Use local macOS shortcuts

Prioritize remote Windows shortcuts

Capture keyboard input exclusively while the remote session is focused, to the extent permitted by macOS

The preferred behavior would be for Windows App to capture and forward supported keyboard combinations before conflicting user-configured global shortcuts are triggered locally.

2. Improve modifier-key handling

Please investigate whether Windows App correctly handles modifier-key transitions generated by Karabiner-Elements, particularly combinations involving Left Option, Right Option, and Space.

3. Clarify keyboard capture capabilities

Please document which macOS global shortcuts Windows App can capture, which shortcuts are reserved by the operating system, and whether the behavior differs between Scancode and Unicode input modes.

Questions for the development team

Is the inability to intercept conflicting macOS global shortcuts an intentional design decision or a known limitation?

Does Windows App use a lower-level keyboard event capture mechanism when the remote desktop session is focused?

Is there a supported or planned option to prioritize remote keyboard input over user-configured macOS global shortcuts?

Could Windows App's handling of modifier-key events be affected by remapping tools such as Karabiner-Elements?

Impact

This issue significantly affects users who rely on both macOS and Windows daily.

Users who have customized their keyboard shortcuts to maintain consistent behavior across operating systems cannot reliably use the same shortcuts within Windows App.

Requiring users to disable or change global macOS shortcuts whenever they connect to a remote Windows session creates unnecessary friction, especially when alternative remote desktop clients provide more flexible keyboard forwarding behavior.

A configurable keyboard capture mode would substantially improve Windows App for power users, developers, and anyone working across macOS and Windows.

Windows for business | Windows Client for IT Pros | User experience | Remote desktop clients
0 comments No comments

2 answers

Sort by: Newest
  1. Daphne Huynh (WICLOUD CORPORATION) 1,980 Reputation points Microsoft External Staff Moderator
    2026-10-14T02:40:34.2133333+00:00

    Welcome to Microsoft Q&A!

    Thank you for taking the time to provide such a detailed report and for documenting the results of your Raycast and Karabiner-Elements testing. The results provide a useful distinction between a general keyboard redirection failure and a shortcut that is being handled locally before it can reach the remote Windows session.

    Based on the behavior you described, the main issue appears to be a local macOS shortcut conflict rather than a failure of the remote Alt + Space shortcut itself.

    Your Experiment C is particularly helpful. When Raycast is completely closed, Option + Space successfully reaches the remote Windows session and activates CmdPal. This indicates that Windows App can forward the shortcut when the key combination is not intercepted locally.

    Apple documents that keyboard shortcuts can conflict between applications and may need to be changed when the same combination is already in use. In this scenario, because Raycast has registered Left Option + Space as a global shortcut, macOS/Raycast handles the combination locally before Windows App can use it for the remote session.

    Microsoft's Windows App documentation also describes how keyboard input and certain key combinations are handled in remote sessions. However, the current documentation does not describe a configurable "capture all keyboard input" or "prioritize remote shortcuts over macOS global shortcuts" option for Windows App on macOS.

    For that reason, your suggestion for a configurable keyboard-capture mode is a reasonable feature request and could improve the experience for users who frequently switch between macOS and Windows.

    1. Karabiner-Elements behavior

    The Karabiner-Elements behavior is worth treating as a separate issue.

    Your observation that the Windows On-Screen Keyboard appears to release Alt when Space is pressed after the Karabiner remapping may indicate that the modifier key state is not reaching the remote Windows session as expected. However, the On-Screen Keyboard observation alone isn't enough to confirm that the problem is specifically within Windows App.

    Because Karabiner-Elements changes the keyboard events before Windows App processes them, the issue could occur at different points in the input path:

    Physical keyboard → macOS/Karabiner → Windows App → RDP keyboard redirection → Windows

    If possible, it would be helpful to compare the following scenarios:

    • Native Option + Space
    • Karabiner-remapped Option + Space
    • Left Option versus Right Option
    • Scancode versus Unicode keyboard input mode, where available
    • Windowed versus full-screen sessions

    Capturing the Windows-side key-down and key-up events would also help determine whether Alt is actually being released before the Space event reaches Windows.

    2. Conclusion

    I would separate this report into two items:

    • Feature request

    Windows App for macOS currently does not document an option that gives the remote session exclusive or prioritized keyboard capture over conflicting macOS global shortcuts. Adding such an option, where permitted by macOS, could significantly improve the experience for users who rely on the same shortcuts across macOS and Windows.

    • Potential compatibility issue

    The modifier-key behavior observed with Karabiner-Elements deserves further investigation. At this stage, additional keyboard-event tracing would be needed to determine whether the modifier state is being changed by Karabiner-Elements, macOS, Windows App, or later in the remote input path.

    For now, the most practical workaround would be to remove or change the conflicting Raycast shortcut. Your own testing shows that Option + Space is forwarded successfully and activates CmdPal once Raycast is no longer capturing the combination.

    Moreover, I would recommend submitting the keyboard-capture behavior through the Windows App feedback channel as a feature request and including your Raycast and Karabiner-Elements reproduction steps. In particular, the difference between the behavior with Raycast enabled and the successful result after completely quitting Raycast provides useful diagnostic information.

    References:

    Use keyboard, mouse, touch, and pen in Windows App - Windows App | Microsoft Learn

    Create keyboard shortcuts for apps on Mac - Apple Support (SG)

    Mac keyboard shortcuts - Apple Support

    Remap Keys and Shortcuts with PowerToys Keyboard Manager | Microsoft Learn

    Compare Windows App features across platforms and devices - Windows App | Microsoft Learn

    Keyboard Input Overview - Win32 apps | Microsoft Learn

    Create keyboard shortcuts for apps on Mac - Apple Support (SG)

    I hope this helps clarify the behavior and provides a useful direction for both the workaround and the feature request.

    If you find it useful, please click Accept Answer.

    Thank you for choosing Microsoft Q&A.

    Was this answer helpful?


  2. AI answer

    2026-10-13T12:43:55.99+00:00

    Windows App for macOS has no documented exclusive keyboard-capture setting, so the current practical resolution is to move or disable Raycast’s conflicting shortcut while using the remote session, select Scancode mode for Alt+Space, and avoid remapping it to Right Option.

    Configure the supported input path

    1. Open Windows App.
    2. In the macOS menu bar, select Connections → Keyboard Mode → Scancode.
      • Alternatively, press Control+Command+K.
    3. Remove the Karabiner rule that converts Left Option+Space to Right Option+Space.
    4. Assign Raycast a nonconflicting activation shortcut, or temporarily disable its Left Option+Space hotkey.
    5. Disconnect and reconnect the remote session, then test Left Option+Space.

    Scancode mode sends key-down and key-up information and is the documented mode for shortcut combinations and other nonprintable input. Unicode mode sends translated characters, so it is not the appropriate mode for reliably testing an Alt+Space chord. Windows App also maps the Option key to the right of Space to Windows AltGr, not ordinary Alt; therefore, the Karabiner conversion in Experiment A does not preserve the intended modifier semantics.^1^

    Your Experiment C already demonstrates that CmdPal and the basic Windows App forwarding path work when Raycast no longer consumes the shortcut. There is no need to repeat that test except while collecting diagnostic logs.

    What is—and is not—currently documented

    Microsoft documents:

    • Automatic mapping for a limited set of common macOS shortcuts.
    • Scancode and Unicode keyboard modes.
    • Right Option mapping to Windows AltGr.
    • Keyboard-layout limitations, including shortcut redirection being supported only for English or English-like layouts and possible mismatches between local and remote layouts.^2^

    Microsoft’s public documentation does not currently describe:

    • A “prioritize remote shortcuts” or exclusive keyboard-capture mode.
    • Which user-configured macOS global shortcuts Windows App can suppress.
    • The low-level macOS event-capture mechanism used by Windows App.
    • A planned release or roadmap commitment for exclusive shortcut capture.
    • Supported behavior for modifier events synthesized by Karabiner-Elements.

    Consequently, the available material does not establish whether interception of Raycast’s shortcut is an intentional product decision or a recognized defect. It also does not establish that the observed Alt release is a Windows App bug: the Right Option/AltGr mapping is a confounding variable that must first be removed.

    Enabling macOS Full Keyboard Access is not a documented solution for this conflict. That accessibility feature enables keyboard navigation of Windows App; it is not documented as an exclusive global-hotkey capture facility.^3^

    Submit two separately scoped reports

    File one feature request for remote-first/exclusive keyboard capture and one bug report for modifier transitions. Separating them prevents the reproducible event defect from being treated solely as a feature request.

    Before submitting the modifier report:

    1. Open Windows App with no active connection.
    2. Select Help → Troubleshooting → Logging.
    3. Choose the Core and UI log levels and an output folder.
    4. Select Start Logging.
    5. Connect and reproduce these two cases:
      • Scancode mode, Raycast shortcut disabled, no Karabiner rule.
      • Scancode mode, Raycast enabled, minimal Karabiner rule reproducing the lost modifier.
    6. Select Stop Logging and retain the generated files.^4^

    Include the Windows App version, macOS version, keyboard layout, connection type, exact Karabiner rule, timestamps, and an event trace showing Alt-down, Space-down/up, and Alt-up if available. Avoid including credentials or session identifiers.

    Submit from Windows App → Help → Submit Feedback, attaching the logs and reproduction matrix.^5^


    References

    1. Use keyboard, mouse, touch, and pen in Windows App
    2. Known issues and limitations of Windows App
    3. Use the Windows app to connect to a cloud PC on macOS with Full Keyboard Access | Microsoft Support
    4. Collect logs from Windows App
    5. Basic troubleshooting for Windows App
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.