
Short answer: enable SendSystemKeys in RealVNC Viewer (or FullscreenSystemKeys in TigerVNC), then press the Windows key where macOS asks for Command. That single setting fixes most conflicts. The 20-row verification table below lets you confirm every common shortcut before you start working.
If you drive a rented Mac over VNC from Windows or Linux, you have almost certainly fired a screenshot on the local desktop when you meant to grab one on the Mac, or Alt+Tabbed locally when you wanted the remote app switcher. The cause is always the same: your VNC client — or the local OS before it — intercepts the key event before it reaches macOS.
This guide shows exactly why that happens, how to pass keys through in RealVNC Viewer, TigerVNC and Remmina, and gives a 20-shortcut checklist to run after every new session. Figment rents a $29 virtual Intel macOS VM (browser-console access) and physical M-series Macs from $95/month; see /mac-hosting for plans. On the physical Macs you connect over a standard VNC-compatible client, so the remaps below apply directly. On the browser console the browser itself can swallow keys — the same three-layer debugging applies, with browser shortcuts added to the list of suspects.
VNC uses the Remote Framebuffer protocol. RFC 6143 §7.5.4 defines the KeyEvent message as a 1-byte message type (value 4), a 1-byte down flag, 2 bytes of padding and a 4-byte X11 keysym. The client sends keysyms, not host virtual-key codes, and the remote server interprets them. There is no automatic Windows-to-Mac modifier translation in the protocol.
Three distinct failures follow from that design:
| Failure mode | Example | Where it happens |
|---|---|---|
| Local OS swallows the key | Win key opens Start menu | Before the VNC client ever sees it |
| VNC client swallows the key | Alt+Tab switches local windows | Inside the client's own shortcut layer |
| Wrong keysym reaches macOS | Ctrl+C lands as Control+C, not Cmd+C | Client did not remap Ctrl→Super |
macOS uses Command (⌘) as its primary modifier — see Apple's keyboard shortcuts reference. Windows and most Linux desktops use Ctrl for the same operations. You have to tell the VNC client what to do about that.
| # | Windows/Linux key pressed | What usually intercepts it | Intended macOS action |
|---|---|---|---|
| 1 | PrtScn / Win+Shift+S | Local screenshot tool | Remote screenshot (Shift+Cmd+3/4) |
| 2 | Alt+Tab | Local app switcher | Remote Cmd+Tab |
| 3 | Ctrl+C / Ctrl+V | Keysym arrives as Control, not Command | Remote Cmd+C / Cmd+V |
| 4 | Win key | Start menu / activities overview | Should map to Cmd on Mac |
| 5 | Ctrl+Space | IBus/Fcitx input method toggle on Linux | Spotlight (Cmd+Space) |
Conflicts 1 and 4 are OS-level; 2, 3 and 5 are a mix of client-level forwarding and keysym mapping. They need different fixes.
The relevant parameter is SendSystemKeys. Confirm the exact name in the Help menu of your installed version — RealVNC has changed parameter names between editions.
SendSystemKeys to true. The client then forwards the Windows key, Alt+Tab, Alt+Esc and Ctrl+Esc to the remote session instead of handing them to Windows.For copy and paste: macOS treats keysym 0xffeb (Super_L — the Windows key) as left Command. With SendSystemKeys on, Win+C, Win+V, Win+X, Win+Z, Win+A all behave as their Cmd equivalents on the Mac. Your Ctrl key keeps its macOS Control role, which is what you want for shell shortcuts inside Terminal.
The authoritative reference is the TigerVNC vncviewer manual. Two parameters matter:
ShortcutModifiers — the modifier combination TigerVNC reserves for its own shortcuts. The default is Ctrl,Alt. Switch it to Ctrl,Shift if you want Ctrl+Alt+* to go to macOS instead.FullscreenSystemKeys — when enabled, TigerVNC grabs the keyboard in full-screen mode and forwards special keys such as Alt+Tab directly to the server.Open the TigerVNC popup menu with Ctrl+Alt+M to change settings mid-session; the menu prefix moves with ShortcutModifiers.
Remmina (GTK VNC plugin):
On connection or Always so your desktop environment stops intercepting keys while Remmina is focused.Linux Ctrl+Space conflict: change the IBus or Fcitx toggle in your desktop keyboard settings, then use Win+Space (forwarded as Super+Space → Spotlight) or bind Spotlight to a key you do not use locally.
Windows keyboards have no Command key. These are the keysyms most VNC servers on macOS honour:
| Windows/Linux key | X11 keysym | macOS reads it as |
|---|---|---|
| Left Win | Super_L (0xffeb) | Left Command (⌘) |
| Right Win | Super_R (0xffec) | Right Command (⌘) |
| Left Alt | Alt_L (0xffe9) | Left Option (⌥) |
| Right Alt | Alt_R (0xffea) | Right Option (⌥) |
| Ctrl | Control_L (0xffe3) | Control (^) |
Every macOS Cmd+key therefore becomes Win+key on your Windows keyboard once the system-keys setting is on.
Run through this after configuring the client. Open TextEdit on the Mac for the editing checks and keep an eye on Mission Control for the system ones.
| # | Press on Win/Linux keyboard | Expected macOS action | Quick verification |
|---|---|---|---|
| 1 | Win+C | Copy selected text | Select in TextEdit, Win+C, paste elsewhere |
| 2 | Win+V | Paste | Paste result from #1 |
| 3 | Win+X | Cut | Select text, Win+X, confirm removal |
| 4 | Win+Z | Undo | Type a word, Win+Z removes the last keystroke |
| 5 | Win+Shift+Z | Redo | Immediately after #4 |
| 6 | Win+A | Select all | Win+A in TextEdit highlights everything |
| 7 | Win+S | Save document | Save sheet or title-bar change |
| 8 | Win+W | Close window | Front window closes |
| 9 | Win+Q | Quit application | Front app quits |
| 10 | Win+Tab | App switcher strip | Switcher appears at centre of screen |
| 11 | Win+Space | Spotlight | Spotlight field opens |
| 12 | Win+Shift+3 | Full-screen screenshot | PNG lands on Desktop |
| 13 | Win+Shift+4 | Region screenshot | Crosshair cursor |
| 14 | Win+Shift+5 | Screenshot toolbar | Toolbar across bottom of screen |
| 15 | Ctrl+Up | Mission Control | All windows spread out |
| 16 | Ctrl+Down | App Exposé | Only front app's windows |
| 17 | Win+M | Minimise front window | Window slides into Dock |
| 18 | Win+H | Hide front application | Windows vanish, app still running |
| 19 | Win+, | App settings/preferences | Front app's settings open |
| 20 | Win+Alt+Esc | Force Quit dialog | Force Quit list appears |
If a row fails, check in order: is the client still intercepting it (client shortcut list), is the local OS still eating it (test with another local app focused), is the Mac's own shortcut customised (System Settings → Keyboard → Keyboard Shortcuts).
Paste this into Terminal on the remote Mac after each new session to see whether a previous user left a system-level modifier remap behind:
# Run in Terminal on the remote Mac
defaults read -g AppleCurrentKeyboardLayoutInputSourceID 2>/dev/null \
&& echo "---" \
&& hidutil property --get "UserKeyMapping" 2>/dev/null \
|| echo "(no custom UserKeyMapping)"
A non-empty UserKeyMapping array means a prior session mapped keys at the HID layer — a frequent explanation for a stubborn remaining conflict.
If your work is editor, browser, SSH and command-line tooling, the $29 virtual Intel macOS VM (2 vCPU, 8 GiB RAM, 80 GiB disk) is the entry point. It runs macOS on Linux/KVM via a browser console, has no GPU acceleration or audio, and is Intel — so Xcode 26 or earlier is the supported toolchain line. Check the exact Xcode/macOS pair you need against Apple's porting notes for Apple silicon before committing.
If you need Apple-silicon execution, local Simulator for recent Xcode, or more RAM and concurrency, physical M-series starts at $95/month (exact chip, RAM and disk are confirmed in the quote; physical plans collect requests until supply is confirmed). The $49 i3 Mac is also request-based. For a managed CI setup — one M-series Mac, CI configuration, backups, monitoring and 30 minutes of monthly support — the Managed Build Mac is $249/month; the two-Mac Managed Mac Team is $999/month.
Request a configuration at /mac-hosting/start.
Related reading: