Karabiner-Elements 16 is out — observations and thoughts for kanata

[malpern]

Karabiner-Elements 16.0.0 shipped yesterday. Congrats to the KE team — it's a solid release. I've been following KE's evolution as someone who uses kanata daily and contributes to the project, and there are some things worth discussing about where keyboard remappers are heading.

What caught my eye in KE 16

JavaScript config generation. Users can now write JavaScript that generates KE's Complex Modifications JSON, with an in-app editor. KE's raw JSON configs are notoriously hard to write, and JavaScript is the most widely-known programming language in the world. This dramatically lowers the barrier to writing complex rules — and in a world where LLMs are increasingly writing configs, JS's massive presence in training data is a pragmatic advantage.

send_user_command and external server integration. KE now has a formalized way to dispatch actions to an external process via IPC, with a companion "user-command-receiver" server. Rather than building every possible action into core, they've created a lightweight extension point.

Accessibility API integration. frontmost_application_if can now detect overlay windows like Spotlight via the Accessibility API, and variable_if gained awareness of UI element properties — role, subrole, title, window geometry. This expands context-aware remapping beyond "which app is frontmost" to "what UI element is focused." It moves KE further along the spectrum toward tools like Hammerspoon.

What I think this means for kanata

KE's send_user_command is something kanata already has — and arguably does better. The push-msg action (#854) already provides lightweight outbound dispatch over TCP without the latency and security concerns of cmd. And kanata's TCP server is bidirectional — external tools can push state in as well as receive events. jtroo has been pretty clear this is by design, not a workaround (#1304).

What strikes me is that the pieces for a real extension ecosystem are mostly already here. jtroo explored a custom-behaviour extension point in #797. The community built push-msg as a practical answer to the latency and security issues with cmd. And on context-aware remapping, jtroo's position has been consistent — it belongs outside kanata, mediated by TCP (#40). Community tools like komokana (Windows), kanata-vk-agent (macOS), and qanata (Linux/Sway) already prove this pattern works.

I've been building KeyPath, a macOS app for kanata config and device management, and it already uses both sides of this pattern — receiving push-msg events for native macOS actions (action handler) and detecting the frontmost app to push state into kanata via TCP (context provider). Next I'm exploring feeding macOS Accessibility API state through the same channel — the same thing KE 16 built into its core, but delivered as an external tool, which is more in line with how jtroo has said this should work.

The pattern that's emerging might be worth naming:

• Context providers: platform-specific processes that watch external state (frontmost app, focused UI element, device connections) and push it into kanata as variables via TCP.
• Action handlers: the outbound side. They listen for push-msg events and perform platform-specific actions — window management, notifications, app launching.
• Kanata core stays focused on remapping, stays cross-platform.

This mostly works today with existing features. What's missing isn't so much new functionality as visibility — jtroo has noted that TCP protocol documentation is scattered across issues and source code (#1304). I wonder if the highest-leverage investment is making the existing integration pattern more discoverable — documenting it, linking to community tools, and positioning push-msg + defvar/switch as the extension surface. That way kanata's core stays lean while the community builds the platform-specific integrations that KE is choosing to absorb into its core.

Worth noting: KE's JavaScript move also makes their configs easier for LLMs to generate. Kanata's S-expression syntax is LLM-friendly (simple, consistent, unambiguous) but there's far less of it in training data. Curated example configs, goal-oriented recipes in the docs, and machine-readable validation output could help close that gap.

The remapping engine remains kanata's deepest advantage. KE is catching up on conditional logic, but kanata's switch, tap-hold variants, defvar, deflocalkeys, and chords are still ahead. The risk isn't that KE overtakes kanata on remapping — it's that kanata's strength becomes a ceiling if users can't easily integrate with the broader system. The TCP extension pattern could prevent that, and most of the pieces are already in place.

Curious what others think — especially whether there's appetite for better documenting the TCP integration pattern and making the community tools more discoverable. And if anyone else is building integrations on the TCP server, I'd love to hear what's working and what's missing.

[gerhard-h]

I wonder how we could make it possible to write a kanata config in natural language and let an LLM write the config.
... more thoughts

• context: tell the AI where to look up documentation an examples
• make a checklist for the user what info he should include in the prompt (or make the LLM ask the missing questions) e.g. plattform, language, layout,...

now the more tricky parts

• the LLM must be able to test its generated config
  a) is it valid (kanata --check)
  b) does it fullfill the specs? - For sure we could tell the LLM to write test cases, and automate them using the kanata simulation tool https://github.com/jtroo/kanata/blob/main/docs/config.adoc#test-your-config This it a little hairy as at the start we don't know if the generated test are alreadey correctly implemented.

Maybe a specdriven development framework like open specs would be well adviced (no experience).

After writing this down I realize, I still asume the user to be a developer with an IDE like vscode installed and vibe coding experinence.