What our run establishes
Our run on October 9, 2026, at commit 8520403 completed installation and compilation, then failed its test command. Our sandbox recorded installation in 7 seconds, compilation in 66 seconds and tests in 10 seconds. Installation and build returned zero; tests returned exit code 101. None of these commands timed out.
The stored harness records each step's success flag, exit code, elapsed time and output tail, plus parsed test summaries. The build output identifies the checkout as v1.13.0-prerelease-2. This is a different target from the v1.12.0 release instructions discussed below. A successful compilation does not verify driver installation, physical input handling, desktop startup or a usable remapping configuration. Those outcomes were not established by our run.
The MrKeyoor testing methodology explains how command results reach the reviews. It provides provenance context, but its current text does not establish which methodology version governed this October 9 run.
Why the stored test counts are not a pass rate
The attached stored parser summaries report 94 passed, 6 failed and 100 total. The supplied evidence warns that Cargo summary output repeats around a replay marker. These historical aggregates may double-count suites; they are not verified unique or exhaustive counts and cannot support a reliable pass rate.
The raw output names failures in direct_held_layer_press_and_release_emit_layer_changes, oneshot_held_layer_timeout_emits_both_transitions_within_one_tick_batch and oneshot_held_layer_consumed_by_keypress_emits_both_transitions_within_one_tick_batch. Each reports failed to parse cfg: No such file or directory (os error 2). These individually named failures explain the observed error within their raw-log scope. They do not replace or reconcile the stored aggregate figures.
The log does not establish why the configuration files were unavailable. Investigate those paths before treating this checkout as a clean development baseline. No audit result was recorded, and security scan coverage is unknown.
What you get from Kanata
Kanata supports layers, tap-hold actions, macros, Unicode output and live configuration reload. Layers let the same physical keys perform different actions, such as navigation on a separate layer, without installing keyboard firmware.
The Kanata README links a configuration guide, basic and comprehensive samples, and an online simulator for configuration validity and simulated input. Start with a minimal mapping, then check it on your actual keyboard before adding timing-sensitive actions or automatic startup. For release binaries, use the sample attached to that release: the v1.12.0 notes warn that the main-branch sample may use unsupported features.
Setup depends on permissions and binary choice
Kanata's documented setup includes prebuilt binaries or a source build using stable Rust. The direct Linux example uses elevated access to open device files and links instructions for avoiding sudo. The macOS route requires a Karabiner driver and permission to intercept keyboard input. Passing compilation does not satisfy these requirements.
The v1.12.0 release instructions distinguish Windows terminal and tray binaries, command-enabled variants, and winIOv2 versus wintercept input mechanisms. The wintercept variant uses Interception. Its release warning says a known issue can disable keyboards and mice until reboot. The platform known-issues document associates Interception input loss with repeated sleep or device disconnection and reconnection.
The README's normal launch requires the launching window to remain open and points to separate background-running arrangements. The Windows release also includes a GUI variant described as a tray application. Choose the binary and startup arrangement together; the documentation does not describe every variant as a foreground terminal process.
macOS limits depend on the version
The v1.12.0 instructions require Karabiner driver v6.2.0 for macOS 11 and newer. They say mouse input is unsupported and the mbck and mfwd mouse-button actions are not operational. They also state that the maintainer lacks macOS devices to validate concise installation instructions.
The supplied main-branch known-issues document discusses mouse-input permissions and mouse-event handling. That differs from the release-specific warning. Keep those source scopes separate rather than applying either description to all versions. Our prerelease checkout was not validated on macOS, so our run cannot settle its mouse compatibility.
The v1.12.0 notes also flag timing and event-order changes in switch and chord behavior. Before upgrading a working setup, replay the tap-hold, chord and layer sequences you depend on.
When to consider another remapper
keyd provides a system-wide remapping daemon using kernel input primitives. Its README documents Linux dependencies, layers, tap/hold overloading and service-manager startup. Consider it as a replacement candidate when Linux is your target and daemon operation suits your setup. This review does not establish that it installs more easily or handles your hardware better.
keymapper supports mappings that depend on application or input context. Its README documents context blocks and separate service and user processes. Consider it as a replacement candidate when those context rules drive your choice. Check the documented restrictions: window titles are unavailable on macOS, process paths have limitations, and Wayland context awareness depends on compositor integration. Neither alternative was tested in our run.
Kanata's README also lists kanata-tray for tray control. It is a companion to Kanata, rather than a replacement remapping engine.
What the ratings mean
These editorial scores use a 1-to-5 scale. A 1 indicates major documented obstacles or very limited supporting evidence; 2 indicates partial support with substantial gaps; 3 indicates useful support with material unresolved work; 4 indicates substantial documented support with explicit limits; 5 indicates comprehensive evidence for the stated dimension. Documentation scores assess coverage, community scores assess visible participation evidence, and maturity scores assess documented release practices. They do not measure adoption or guarantee reliability.
Setup ease is 3: our build passed, but the test command failed and desktop setup remains unverified. Documentation is 5 for coverage of configuration references, samples, platform instructions, binary variants and known issues; this does not verify every instruction. Community is 4 for the README's named editor, tray and platform companion projects and contribution channels, without measured adoption or response times. Maturity is 4 for documented release variants, compatibility requirements and behavior-change warnings, limited by the failed test command and absent desktop validation.