If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/input-leap/input-leap shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Slowing — last commit 5mo ago

• Last commit 5mo ago
• 22+ active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 5mo ago
• ⚠ Concentrated ownership — top contributor handles 51% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live input-leap/input-leap repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/input-leap/input-leap.

What it runs against: a local clone of input-leap/input-leap — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in input-leap/input-leap | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 189 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of input-leap/input-leap. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/input-leap/input-leap.git
#   cd input-leap
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of input-leap/input-leap and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "input-leap/input-leap(\\.git)?\\b" \\
  && ok "origin remote is input-leap/input-leap" \\
  || miss "origin remote is not input-leap/input-leap (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 189 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~159d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/input-leap/input-leap"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Input Leap is an open-source software KVM (keyboard-video-mouse) switch that lets you control multiple computers with a single keyboard and mouse by moving the cursor to screen edges or using hotkeys to switch focus. Unlike its predecessor Synergy, it focuses on simplicity and reliability, supporting Windows, macOS, Linux, and FreeBSD with a client-server architecture where the server machine shares input devices to multiple client machines. Monolithic C++ codebase organized by build system (CMake at root), with platform-specific code for Windows (Inno installer in dist/inno/), macOS (Objective-C++ in sources, bundle template in dist/macos/bundle/), and Linux (Debian packaging in dist/debian/, Flatpak manifest in dist/flatpak/). The server/client architecture is code-level, not directory-structured.

System administrators, power users, and developers who work across multiple machines (desktop, laptop, server) and want seamless input device sharing without hardware KVM switches or proprietary solutions like Synergy. Contributors are open-source enthusiasts maintaining cross-platform C++ software.

Actively developed and production-ready. The project is a community fork of Synergy 1.x with modern maintenance (evidenced by CMake build system, GitHub Actions CI in .github/workflows/builds.yml, Debian/Flatpak/Inno packaging in dist/), and appears to have regular commits. No star count visible in provided data, but the structured release process (RELEASING.md) and multi-platform distribution indicate maturity.

Standard open source risks apply.

No specific recent changes visible from file list alone, but the presence of GitHub Actions workflows (builds.yml) and Dependabot config (.github/dependabot.yml) indicates active CI/CD maintenance. Multi-platform distribution updates (Flatpak YAML, Debian rules) suggest ongoing cross-OS compatibility work.

Clone with git clone https://github.com/input-leap/input-leap.git && cd input-leap, then build using CMake: mkdir build && cd build && cmake .. && make. Run ./inputleap for the GUI or check dist/debian/ or dist/inno/ scripts for platform-specific installation.

Daily commands: After building with CMake (cmake .. && make), run the GUI with ./inputleap (server mode) on the primary machine, configure screen layout in 'Configure server', then run ./inputleap in client mode on secondary machines pointing to the server's IP. Alternatively, use packaged installers from dist/inno/ (Windows), dist/debian/ (Linux), or dist/macos/bundle/ (macOS).

• CMakeLists.txt: Root build configuration; understanding cmake version, compiler flags, and module structure is essential to build the project locally
• .github/workflows/builds.yml: Defines CI/CD pipeline for Windows, macOS, and Linux; shows expected build environment, dependencies, and test commands
• README.md: Authoritative usage guide; explains server/client setup, screen name matching requirements, and Scroll Lock behavior that affects mouse switching
• dist/debian/control: Declares runtime dependencies for Linux builds; shows what packages Input Leap needs (Qt, OpenSSL, etc.)
• RELEASING.md: Documents release process, versioning scheme, and distribution targets (Debian, Flatpak, Inno); critical for understanding how to cut releases
• .github/dependabot.yml: Automated dependency updates config; shows which package managers and ecosystems are actively monitored
• dist/flatpak/io.github.input_leap.input-leap.yaml: Flatpak manifest specifying all runtime dependencies, SDK version, and permissions needed for sandboxed Linux distribution

Start in src/ for core logic (likely split by common/, server/, client/ directories based on typical Input Leap structure). Platform-specific code: src/platform/windows/, src/platform/mac/ (Objective-C++), src/platform/linux/. GUI code likely in src/gui/. Test cases expected in tests/ or test/. Configuration parsing: look for config/ directory.

1. Screen name case-sensitivity: README explicitly warns screen names must match exactly between server config and client hostname; case-sensitivity bugs are easy to introduce. 2. Scroll Lock blocking: Mouse switching is globally disabled if Scroll Lock is active; client code must respect this behavior. 3. Clipboard limitations: Not supported on Linux/Wayland at all; feature requests will be blocked by platform constraints. 4. Multi-platform compilation: Building requires platform-specific headers (Windows SDK, Objective-C++ toolchain for macOS, X11/Wayland dev libraries for Linux); developers must have full cross-platform setup or will hit missing-dependency errors. 5. IRC-only support: No Discord/Slack; async communication via GitHub issues is the primary async channel.

• KVM Switch (hardware→software emulation) — Core problem Input Leap solves; understanding traditional hardware KVM switches helps explain why software emulation is valuable and what constraints it removes/adds
• Client-Server Input Forwarding — Input Leap's architectural foundation; server captures keyboard/mouse events and forwards them to client machines over network sockets with low latency requirements
• Platform Abstraction Layers (PAL) — Input Leap supports 5+ OSes (Windows, macOS, Linux, FreeBSD) requiring platform-specific input capture; Objective-C++ for macOS and conditional compilation show PAL patterns
• X11 vs Wayland display servers — Linux clipboard sharing explicitly unsupported on Wayland in README; understanding the differences explains architectural constraints and why clipboard forwarding is fragile on Linux
• CMake build system and cross-compilation — CMake is the only build system visible in this repo; mastering CMakeLists.txt, platform-specific flags, and dependency detection is required to contribute build improvements or port to new platforms
• Flatpak sandboxing and permissions — Input Leap distributes via Flatpak (dist/flatpak/); understanding sandbox permissions (why clipboard/input capture requires special portals) explains distribution testing constraints
• Objective-C++ interop (C++ ↔ Cocoa) — macOS builds use Objective-C++ (70K LOC); knowing how to bridge C++ networking code with native Cocoa GUI is essential for macOS-specific contributions

• symless/synergy-core — Input Leap's direct predecessor and fork basis; understanding Synergy's architecture and design decisions provides context for Input Leap's simplification goals
• debauchee/barrier — Another Synergy fork competing in the same KVM-switch space; useful for comparing feature parity, multi-platform support, and community size
• microsoft/vcpkg — C++ dependency management relevant for Windows/macOS builds; Input Leap's minimal dependencies may benefit from vcpkg integration for consistent cross-platform compilation
• flatpak/flatpak — Sandboxing framework that Input Leap targets via dist/flatpak/; understanding Flatpak permissions and runtimes is essential for Linux GUI application distribution
• opencv/opencv — Not directly related, but represents the scale of cross-platform C++ GUI projects with similar CMake/CI/packaging complexity that junior contributors can reference for patterns

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add platform-specific integration tests for KVM switching functionality

The repo has distribution configs for Windows (Inno, WiX), macOS (bundle), Linux (Debian, RPM, Snap, Flatpak), but lacks visible integration tests validating that mouse edge detection and keyboard focus switching work correctly across these platforms. Given Input Leap's core functionality depends on platform-specific input handling, adding CI workflows and test suites for each platform would catch regressions early and increase contributor confidence.

• [ ] Create src/tests or tests/ directory with platform-specific test modules (Windows, macOS, Linux)
• [ ] Add GitHub Actions workflow in .github/workflows/ to run platform tests on multiple OS matrices
• [ ] Write integration tests validating mouse edge detection triggers screen switching on each platform
• [ ] Document test setup in doc/ (e.g., doc/DevelopmentTesting.txt) explaining how to run tests locally

Create comprehensive manpage documentation for input-leap.conf configuration

The repo includes doc/input-leap.conf.example and doc/input-leap.conf.example-advanced as reference configs, but dist/debian/inputleap.manpages references manpages that should exist. A complete manpage documenting all configuration options, sections (screens, links, aliases), and examples would help users and reduce support burden on IRC channels (#inputleap).

• [ ] Create doc/input-leap.conf.5 (or similar) following man-page standards with SYNOPSIS, DESCRIPTION, OPTIONS, EXAMPLES sections
• [ ] Cross-reference this manpage in dist/debian/rules and update dist/debian/docs to include it
• [ ] Add examples from doc/input-leap.conf.example and doc/input-leap.conf.example-advanced into the manpage EXAMPLES section
• [ ] Update README.md with a 'Configuration' section linking to the manpage location

Add GitHub Actions workflow for building and testing Flatpak distribution

The repo includes dist/flatpak/io.github.input_leap.input-leap.yaml but .github/workflows/builds.yml likely doesn't validate Flatpak builds. Since Flatpak is a major distribution method for Linux desktop applications and listed in the README badges area, adding a workflow to build and validate the Flatpak manifest would catch breakage early and ensure the package format remains functional.

• [ ] Review .github/workflows/builds.yml to confirm Flatpak testing is missing
• [ ] Create .github/workflows/flatpak-build.yml with steps to run 'flatpak-builder' on dist/flatpak/io.github.input_leap.input-leap.yaml
• [ ] Add caching for Flatpak build dependencies to optimize CI runtime
• [ ] Document Flatpak build process in doc/BuildingFlatpak.txt or similar, referencing the workflow

• Add unit tests for screen name matching logic in src/server/config/ to ensure case-sensitivity is enforced and validated; currently no visible tests/ directory suggests test coverage is incomplete
• Document Wayland clipboard limitations in README.md with a subsection under 'Known Issues' linking to relevant GitHub issues; helps new contributors understand platform gaps upfront
• Implement automated Flatpak CI build in .github/workflows/builds.yml to validate dist/flatpak/io.github.input_leap.input-leap.yaml on every commit; currently only source builds are tested

Input Leap appears to be a moderately secure open-source KVM software project. The main concerns are: (1) outdated Visual C++ redistributable references in Windows installers, (2) lack of visible dependency lock files for reproducible secure builds, (3) potential code execution vectors through installer scripts, and (4) missing security policy documentation. The project structure is well-organized with proper separation of build artifacts and distribution files. No hardcoded secrets, SQL injection risks, or XSS vulnerabilities are apparent from the visible file structure. Recommended actions include updating build dependencies, implementing cryptographic verification for downloaded files, and establishing a clear security disclosure policy.

• Medium · Outdated Visual C++ Redistributable References — dist/inno/scripts/products/vcredist2017.iss. The codebase references vcredist2017.iss for Visual C++ 2017 redistributables in Windows installer scripts. Visual C++ 2017 is outdated and may contain known vulnerabilities. Modern versions (2019, 2022) should be used instead. Fix: Update to vcredist2019.iss or vcredist2022.iss and ensure the latest Visual C++ redistributable package is bundled with the installer.
• Medium · Potential Code Execution via Installer Scripts — dist/inno/scripts/isxdl/isxdl.dll, dist/scripts/download_release.py. The Inno Setup installer includes .dll files (isxdl.dll) and .pas scripts that could potentially be exploited if the installer is compromised or if there are vulnerabilities in the Inno Setup framework itself. Additionally, the dist/scripts/download_release.py downloads files at build time without explicit integrity verification mentioned in visible files. Fix: Implement cryptographic signature verification for downloaded files. Use code signing for installer executables. Keep Inno Setup framework updated to the latest version.
• Low · Insufficient Information on Dependency Management — CMakeLists.txt, cmake/ directory. The CMakeLists.txt and dependency management strategy are not fully visible in the provided file structure. No lock files (package-lock.json, requirements.txt, Cargo.lock, etc.) are shown, making it difficult to ensure reproducible builds and verify dependency integrity. Fix: Implement and maintain dependency lock files. Use CMake's FetchContent with SHA256 verification or similar mechanisms. Document all external dependencies and their versions.
• Low · Sensitive Information in Example Configuration Files — doc/input-leap.conf.example*, doc/org.input-leap-foss.org.inputleap*.plist. Configuration example files are provided in the dist and doc directories. While these are examples, they may contain sensitive patterns or documentation about the application's attack surface. Fix: Review configuration files to ensure no sensitive defaults are documented. Add clear security warnings in example configs about properly securing authentication and communication channels.
• Low · Missing Security Policy Documentation — Repository root. No SECURITY.md or security policy file is visible in the repository structure, which is important for responsible disclosure of vulnerabilities. Fix: Create a SECURITY.md file documenting how to responsibly report security vulnerabilities to the maintainers.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.