Bridle: One Config Manager for Seven Agentic Harnesses

The problem is directory drift between harnesses

Every agentic coding harness invented its own place to put skills. Claude Code reads ~/.claude/skills/. OpenCode reads ~/.config/opencode/skill/, singular. Goose uses ~/.config/goose/skills/. Copilot CLI uses ~/.copilot/skills/. Crush uses ~/.config/crush/skills/. The README lays this out in a table, and the table is the argument for the project. A skill that is a directory of markdown and a manifest for one harness is not directly usable by another, because the path differs and, for MCP servers, the schema differs too: Claude Code reads ~/.claude/.mcp.json, OpenCode reads opencode.jsonc, Goose reads config.yaml, Copilot CLI reads ~/.copilot/mcp-config.json, and Crush reads crush.json. Bridle is aimed at the engineer who runs three of these at once and has stopped remembering which MCP server is configured where. It is not aimed at someone who uses one harness and edits one file. The secondary problem it addresses is profile switching: keeping a work configuration and a personal configuration for the same harness and swapping between them without hand-editing JSON.

How Bridle translates a skill between harnesses

The mechanism described in the README is a scan, a selection, and a rewrite. You point bridle install at a GitHub repository, either as owner/repo or a full URL. Bridle scans that repository for skills, agents, commands and MCP definitions. You pick which components you want, then pick target harnesses and profiles. Bridle then rewrites paths and configuration for each target. The README's own example is a skill written for Claude Code that lives under ~/.claude/skills/ and needs to land at ~/.config/opencode/skill/ for OpenCode. The same translation applies to MCP schemas, which is the harder half, because JSON and YAML shapes differ between harnesses rather than just the filename. Note what the README does not describe: it does not say how conflicts between an incoming component and an existing one are resolved beyond a --force flag, and it does not describe a translation manifest or a dry-run mode. For a tool whose whole value is rewriting files in directories you care about, that is the thinnest part of the documentation.

Profiles are copies, not symlinks

The README is explicit about the model: profiles are saved configurations, and when you switch, Bridle copies the active profile's configuration into the harness's config directory. That is a copy, not a symlink and not a generated include. The consequence is that the harness config directory is the live state, and the profile store is a snapshot. If you edit a setting directly in ~/.claude/ after switching to the work profile, the profile on disk no longer matches what the harness is running, and bridle profile diff will show the drift only if you think to run it. There is a profile_marker config key, described as creating marker files for debugging, which suggests the project is aware that knowing which profile is active is not always obvious from the harness side. The copy model is the right call for harnesses that do not support includes, but it makes the switch operation destructive in the sense that it overwrites the target directory's configuration. Treat the profile store as the source of truth and the harness directory as disposable, or you will lose edits.

Getting it running and the config keys that matter

Installation has several routes. Without installing, npx bridle-ai, bunx bridle-ai or pnpm dlx bridle-ai will run it once. For repeated use, npm install -g bridle-ai, bun install -g bridle-ai or pnpm add -g bridle-ai. There is also brew install neiii/bridle/bridle, cargo install bridle, and a from-source path: git clone https://github.com/neiii/bridle && cd bridle && cargo install --path . The quick start sequence in the README is bridle to launch the TUI, bridle status to see what is configured across all harnesses, bridle profile create claude work --from-current to snapshot the current Claude Code configuration as a profile called work, and bridle profile switch claude personal to activate a different one. Bridle's own configuration lives at ~/.config/bridle/config.toml. The keys are profile_marker, editor, default_harness, and a [tui] table with a view key. The README's example sets editor = "code --wait", which matters because bridle profile edit shells out to that command, so the --wait flag is what makes the editor block until you close the file. default_harness controls which tab opens on launch. Every command accepts -o, --output with text, json or auto, where auto means text for a TTY and JSON for pipes. That last detail is the one that makes Bridle scriptable: bridle status -o json is usable from a shell prompt or a CI step without parsing a table.

Support is not uniform across the seven harnesses

The supported harnesses table is the honest part of the README. Claude Code, OpenCode, Goose and Copilot CLI are listed as full support. Crush is full support with the parenthetical (skills + MCP), which means agents and commands are not covered there. Amp is marked Experimental (ish), and the parenthetical is doing real work: the README does not say which of skills, agents, commands or MCPs are handled for Amp. Droid appears in the repository description as a supported harness but has no row in the supported harnesses table and no config location listed, so anything about Droid beyond its name is unconfirmed from the supplied material. Uninstall carries the tag [experimental] as well, which is worth weighing before you let Bridle install a batch of components: bridle uninstall <harness> <profile> is described as interactively removing components, and an experimental removal path is a weaker guarantee than an experimental install path, because the failure mode is leftover files in a config directory rather than a missing feature.

Where Bridle is the wrong tool

If you use one harness, Bridle adds a layer between you and a file you could edit directly. The translation engine has nothing to translate, and the profile store duplicates a configuration you already have. The copy-on-switch model also makes Bridle a poor fit for anyone who edits harness configuration live and expects those edits to persist across a switch. And there is a class of user for whom the whole premise is wrong: if your skills are already shared through a git repository that each harness reads from its own path, a dotfiles manager with per-harness templates gives you the same result with no new binary and no new config format. Bridle's advantage over that approach is the interactive selection step and the schema translation for MCP definitions, which a template system cannot do without you writing the translation yourself. If your MCP servers are few and static, that advantage does not materialise.

Alternatives and the actual difference in approach

The obvious comparison is a dotfiles manager such as chezmoi or GNU Stow, or a plain git repository of dotfiles. Those tools move files to fixed destinations. You decide, per file, where it goes, and the mapping is written by hand. Bridle inverts that: you name a source repository, and Bridle decides the destinations by reading the harness table. That is the real difference, and it cuts both ways. A dotfiles manager cannot install a component from a third-party repository into five harnesses at once, and it cannot convert an MCP definition from JSON to YAML. Bridle cannot give you the arbitrary per-file control that a dotfiles manager gives you, and it does not attempt to manage anything outside the harness config directories. The second comparison is each harness's own plugin or extension mechanism, such as Claude Code's plugin directories under ~/.claude/plugins/. Those are per-harness by construction, which is fine until you want the same agent available in OpenCode, where it belongs under ~/.config/opencode/agent/. Bridle's value is precisely the cross-harness step, so if you never take that step, you are paying for translation you do not use.

Maintenance cost and the MIT licence

Bridle is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive arrangement and it is compatible with vendoring the tool into an internal setup. It is not legal advice, and if you redistribute a modified Bridle you should read the licence text rather than this summary. On maintenance: the release history supplied shows v0.2.7 on 2026-01-16, v0.2.8 on 2026-01-20, and v0.2.9 on 2026-01-30, which is a fast cadence of small version bumps rather than a stable 1.0 line. The last push to the repository is dated 2026-08-15. A pre-1.0 tool that rewrites files in your config directories means you should pin a version. With Cargo that is cargo install bridle --version 0.2.9, and with npm it is npm install -g bridle-ai@0.2.9. The upgrade cost is not the binary; it is the possibility that a later release changes how a profile is laid out on disk, which would make profiles created by 0.2.9 unreadable or, worse, readable but subtly different. The README does not describe a profile format version field, so that risk is unmitigated as far as the supplied material shows.

Editorial conclusion

Adopt Bridle if you run two or more harnesses and keep losing track of which skills and MCP servers live where, and if you are comfortable with a project whose Amp and uninstall paths are flagged experimental. Do not adopt it if you need a single harness configured once, or if you expect uninstall to be a finished operation. Before trusting it with a working setup, run bridle status and bridle profile diff against a copy of your existing config, and confirm that the profile switch writes what you expect into ~/.claude/ or ~/.config/opencode/.

Official sources

1. Issues
2. License: MIT
3. neiii/bridle on GitHub
4. README
5. Releases