What Keylore actually does to your configs
Last time I said I got bored of editing configs blind and shipped a macOS app for it. This post is the product tour. What Keylore does when you point it at a desk full of tool configs, and why the boring safety choices are the point.
I still open LazyGit, Ghostty, AeroSpace, and Zellij every week. Each one keeps its own file shape. TOML over here. YAML over there. KDL if you are in Zellij land. Ghostty still likes its own line format. None of that is wrong. It just means I spent years grepping docs for keys I had already half-remembered.
Keylore is the app I wanted on that desk. Local-first. No account. No "sync your dots to our cloud" pitch. Point it at a workspace or a repo layout, and it tries to find the configuration files that already live there.
Finding the mess
Discovery is the first job. You pick a root. Keylore walks the layout it understands and surfaces the apps it can talk to. In v1 that means the four I actually live in: LazyGit, Ghostty, AeroSpace, Zellij.
On my machine that root is usually a dotfiles-style tree, the same place I keep everything else under version control. Keylore is not hunting your entire home directory for fun. It is looking for known layouts and known files. When it finds one, you pick the app in the sidebar and go to work.
If a tool is not there, it is not there. I did not invent a universal plugin marketplace on day one. The list is short on purpose. I would rather ship four honest adapters than a fake "supports everything" page. Starship and Atuin have kit sketches in the repo tree for later; they are not the v1 promise on the README. Weekly tools first.
Apple Silicon only. macOS 14+. Same limits as the README. That is the machine I build on. If you are on Intel, this is not your app yet, and I am not going to soft-pedal that.
Editing without pretending
Once an app is selected you can open its config. The files stay in their native formats. Keylore is not rewriting your Ghostty config into some private JSON of the week and hoping you never open the file again.
There is a text path with previews so a save is less of a coin flip. Syntax highlighting is enough to stop me from merging two KDL blocks with my face. There is also a structured path for options the kits and catalogs know about. Toggles, fields, rows for keybinds when the catalog has them. The goal is simple: see the option space on screen instead of hunting the same man page for the third time this month.
Some apps are happier in the form. Some still want the raw file. Both paths exist because I use both on the same afternoon.
I care about dirty state more than I should. If you changed a form and something else wants to overwrite the disk, the app should make you deal with that. Silent clobber is how people lose a half-hour of tweaks. The tests in the repo are full of that class of boring check. Form save writes. Dirty form blocks a reckless deploy. Stale edit sessions get rejected. Unsexy. Correct.
External edits still happen. You will open the file in another editor. The world is messy. Keylore has to live with that instead of pretending it owns the only process on the machine.
Template kits, with a hard stop
Kits are optional. That sentence does a lot of work.
A kit is data. Catalogs of options. Default config fragments. Declarative payloads you can inspect. You opt in before anything lands. Kits do not ship executables. They do not run code on your machine. If a kit wants to "help" by running a script, it does not belong in this design.
I have installed enough "helpful" packages that quietly grew hands. Dotfile managers that shell out mid-install. Theme packs that assume your PATH. I wanted consent that means something. You see what is offered. You say yes. Then the data moves. If you never say yes, nothing installs.
Signed and declarative is the bar for the kit path. Local-first still holds. The kit is not a remote code delivery channel with a friendly name. If that sounds strict, good. Config managers that get clever with execution are how you wake up with a shell you do not recognize.
Shortcuts you can actually see
Most of these tools have defaults. Then you override three of them and forget the rest exist.
Keylore has a shortcuts and defaults view for that. Effective keybindings from the official defaults plus your overrides, in one place. If a tool has a key you never set, you can still see what it does out of the box. That is half the reason I built the app. I was tired of "is this bound or am I imagining it" at 1am.
It is not a remapper for every app on macOS. It is the keybind story for the tools Keylore already understands. Scope stays small. The list stays honest.
What v1 is not
v1 is not a full Nix-shaped declaration of your whole life. It is not a cross-platform GUI. It is not "bring any random TOML and we magic a form." Adapters matter. Catalogs matter. Ghostty's line format is not LazyGit's YAML, and the code knows that.
It is also not a finished release machine story. The code is public. Clone it. Build the Keylore scheme on an Apple Silicon Mac with a current Xcode. I already wrote about the Actions minutes I burned elsewhere. A pretty DMG from CI is still on the list. Source is the truth today.
If you want brew or a signed download later, that is the README path once the pipeline is awake again. Until then I would rather you have the repo than a broken "download now" button.
The shape I keep coming back to
Discover what is on disk. Edit it in the format the tool already uses. Offer structure when the catalog knows the option. Install kit data only with consent. Show defaults and overrides for shortcuts. Stop before the app starts executing strangers' code.
That is the whole product pitch without the marketing coat of paint. If you only read this post and never the entry one, you should still know what you are installing: a native Mac app for a small set of developer configs, local-first, kit-shy on purpose.
More tools can land later. More adapters. More catalog depth. I will ship those when I use them weekly, not when a feature matrix looks lonely.
Series and where to go
Day 1 was the why: I got bored of editing configs blind, so I shipped a macOS app.
Day 3 is the how: planning with GPT, implementing with Grok 4.5, the reiterate loop, and the release mess. If you care more about the agent day than the option inspector, skip ahead when that post is up.
Repo lives here either way: kaankoken/keylore. Open the workspace. Build Release. Point it at a real config root and try to break the boring paths. That is more useful feedback than a star on a README I wrote at 11pm.