One keyboard, one mouse, one clipboard — shared across your Mac, Windows, and Linux machines on the same LAN.

Move your cursor off the edge of one screen and it lands on the next machine. Your keyboard follows, and the clipboard (text and images) syncs automatically. No KVM hardware, no cables.

中文说明

Display layout	Devices	Settings

1. Install on both machines. Download the installer for each OS from the latest release.
2. Pick roles. On the machine whose keyboard and mouse you want to share, open MyKVM and keep Server mode (the default). On the other machine, open MyKVM and switch to Client mode in Settings.
3. Connect. On the same LAN the two find each other automatically. Otherwise open Devices, type the other machine's IP (optionally IP:port), and click Add. Only devices that report their screen info join the layout.
4. Arrange screens. Open Layout and drag the monitors so their touching edges match how they sit on your desk.
5. Cross over. Push the cursor past a shared edge — it moves to the other machine. The keyboard follows, and copy/paste works in both directions.

• macOS (server). Grant MyKVM both Accessibility and Input Monitoring under System Settings → Privacy & Security. These are required to capture and inject keyboard/mouse input. Signed builds keep the grant across updates; if it ever drops, toggle it off and on.
• macOS first launch. Builds are free self-signed (not Apple-notarized), so Gatekeeper warns the first time. Right-click the app → Open → Open to allow it once.
• Windows. No special permission for normal use. Run as Administrator only if you need to control elevated/admin windows.
• Linux. If you use the AppImage, mark it executable (chmod +x).

• Trusted LAN only. There is no user pairing/PIN yet, and LAN discovery is plaintext and unauthenticated. Do not expose the ports to public or untrusted networks.
• Input and clipboard ride an encrypted QUIC/TLS connection pinned to the peer's advertised certificate, but MyKVM is a prototype and is not hardened for hostile networks.
• The clipboard syncs text and images, not files.
• macOS builds are self-signed, not notarized — expect a Gatekeeper prompt on first open.
• Experimental software: the protocol and behavior may change between versions.

• Runs in Server or Client mode.
• Discovers nearby peers on the LAN.
• Supports manual peer connection by host or IP.
• Detects local displays and lets you arrange multi-monitor layouts.
• Shares keyboard and mouse input over an encrypted QUIC connection.
• Syncs clipboard text and images over the same encrypted connection.
• Provides light, dark, and system theme modes.
• Includes English and Simplified Chinese UI.
• Supports tray behavior for hiding and restoring the main window.
• Checks GitHub Releases and updates itself in place.

MyKVM is an experimental early release. It is useful for local testing and iteration, but it is not hardened for untrusted networks. See the Releases page for the current version and installers.

• License: MIT
• Default ports: UDP 47833 (discovery) and UDP 47834 (QUIC transport)
• Clipboard payload caps: 256 KB text, 32 MB image
• Transport security: input and clipboard run over a TLS 1.3 (QUIC) connection pinned to the peer's advertised certificate
• Security model: trusted LAN prototype
• Not yet included: user pairing/PIN, authenticated discovery, and production transport hardening

Do not expose the transport ports to public or untrusted networks.

MyKVM runs two channels. LAN discovery uses a plain UDP port; input and clipboard run over an encrypted QUIC connection on a second UDP port.

The discovery port is configurable in Settings (default UDP 47833); the QUIC transport port defaults to the discovery port + 1 (UDP 47834). Both auto-fall-back through nearby ports if a port is taken, and can use a system-selected port if needed. Peers advertise their active discovery port, QUIC port, transport public key, and protocol version, so discovered and manually added devices connect to the right port and pin the right certificate.

The QUIC connection is TLS 1.3 encrypted: each peer generates a self-signed certificate at startup and advertises it during discovery, and the connecting side pins that certificate, so input and clipboard traffic is encrypted and bound to the advertised peer. Discovery itself is still plaintext and unauthenticated, so keep MyKVM on a trusted LAN.

• Node.js 22+
• Rust stable
• Platform desktop toolchain:
  • Windows: Microsoft C++ Build Tools
  • macOS: Xcode Command Line Tools
  • Linux: WebKitGTK and appindicator development packages

Install dependencies:

npm install

Run the web UI:

npm run dev

Run the Tauri desktop app:

npm run tauri:dev

Build without bundling installers:

npm run tauri:build

Build desktop bundles:

npm run tauri:bundle

Windows:

powershell -ExecutionPolicy Bypass -File .\scripts\check-dev-env.ps1
powershell -ExecutionPolicy Bypass -File .\scripts\run-tauri-dev.ps1

macOS and Linux:

sh scripts/check-dev-env.sh
sh scripts/run-tauri-dev.sh

macOS input capture and injection require Accessibility and Input Monitoring permissions in System Settings.

Run these before opening a pull request or cutting a release:

npm run build
npm run lint
cargo check --manifest-path src-tauri/Cargo.toml

Git itself only stores and pushes source history. GitHub Actions does the actual packaging on GitHub-hosted runners.

The release workflow watches pushes to main:

• feat: publishes the next minor version, such as v0.1.0 to v0.2.0.
• fix: publishes the next patch version, such as v0.1.0 to v0.1.1.
• Other prefixes run normal checks but do not publish a release.
• If no release tag exists yet, the first feat: or fix: push publishes v0.1.0.

Release notes come from the ## [Unreleased] section of CHANGELOG.md (user-facing wording), falling back to filtered commit subjects. Keep that section up to date as you land changes.

Example:

git commit -m "feat: initial desktop release"
git push origin main

The workflow creates the git tag, builds macOS, Windows, and Linux bundles, then publishes a GitHub Release with the generated installers.

Issues and pull requests are welcome. Keep changes focused, document behavior that affects the protocol, and verify both the web build and the Tauri backend when touching shared runtime code.

See CONTRIBUTING.md for commit prefixes and versioning notes.

MIT. See LICENSE.