Mac Host: Korean Input Source Causes Modifier Key Misinterpretation Across All Clients (Mac, iPad, iPhone)

Hi Jump Desktop Team,

I’d like to report a reproducible keyboard issue that appears to affect any client connecting to a Mac host, regardless of whether the client is a Mac, iPad, or iPhone.

Environment

Host: macOS (latest)
Jump Desktop Connect: latest version
Viewer devices tested:
- Mac
- iPad
- iPhone
Protocol: Fluid

Issue

The issue depends on the Host Mac’s active input source, not the client device.

When the Host Mac is using the Korean input source, the remote keyboard behaves as if a modifier key (Option or Command) is being held.

Typical symptoms include:

Typing English triggers keyboard shortcuts instead of normal text.
Some keys behave as if Option or Command is permanently pressed.
Korean input appears mostly normal.

Reproduction

This is 100% reproducible.

Connect to a Mac Host from any client (Mac, iPad, or iPhone).
Set the Host Mac input source to Korean.
Start typing in English from the remote client.
Keyboard input becomes incorrect.
Without disconnecting, switch the Host Mac input source to ABC.
The issue disappears immediately.
Switch the Host back to Korean.
The issue immediately returns.

No reconnect is required.

The issue appears and disappears instantly based only on the Host’s active input source.

Investigation

I verified that:

No custom keyboard mappings are configured (HIDKeyboardModifierMappingPairs = ()).
Sticky Keys are disabled.
No third-party keyboard remapping software is installed.
Both Jump Desktop and Jump Desktop Connect are fully up to date.
The behavior is identical from Mac, iPad, and iPhone clients.

This strongly suggests that the problem is related to how Jump Desktop interprets keyboard events when the Host Mac is using the Korean input source.

Existing Reports

I found several community posts describing related issues:

English typing behaves as if Command is pressed. Your team acknowledged this as an internal bug.
Korean input source causing Command-key issues.
Client and Host using different input languages causes incorrect keyboard behavior.

However, I haven’t found a report that clearly identifies the Host Mac’s active input source as the deterministic trigger.

Workaround

The current workaround is to manually switch the Host Mac to ABC before connecting.

This immediately resolves the problem, but it is inconvenient because it must be done every time.

Request

Could your team investigate how keyboard events are translated when the Host Mac is using the Korean input source?

Based on my testing, the Host’s input source alone is sufficient to trigger or resolve the issue, regardless of whether the client is a Mac, iPad, or iPhone.

I’d be happy to provide additional testing or logs if needed.