I use Claude Code and Codex side by side. The models are different. The setup work is mostly the same, and it is mostly duplicated.
The same MCP server has to be declared in Claude Code's .mcp.json and Codex's config.toml. Skills live in separate directories. A prompt is a command file in one client and a section of an instruction file in the other. Change one side, forget the other. Repeat next week.
I wrote a sync script first. It moved files, but it did not answer the questions I had: what does this skill look like, where did this MCP server come from, and has its upstream changed?
Context Hub is the tool I built after that. It keeps skills, MCP servers, prompts, plugin packs, and environment variables in one local library, then writes each asset into the agent's own workspace or global directory.
What it does
- One catalog for five asset types.
- Delivery to a workspace or to an agent's global directory.
- Media previews in skill and prompt details, so I can inspect an asset before installing it.
- Upstream source tracking for skills and plugin packs.
- Global search with
Ctrl/Cmd+K. - A desktop app, a standalone CLI, and a local web page, all backed by the same server.
The library lives in ~/.context-hub. Set CONTEXT_HUB_HOME to move it.
The hard part: editing configs without rewriting them
MCP was the part I underestimated.
A server declaration is small: a command with arguments and environment variables, or a URL. The file around it is not. Claude Code configs may contain comments, trailing commas, and other project settings. Codex's TOML may have hand-written comments and a key order someone chose.
The obvious implementation is to parse the file into an object, change the object, and serialize it back. That gets the value right and loses everything around it. Comments disappear, indentation changes, keys move. The next time the user opens the file, it looks like someone else's.
Context Hub edits the text instead. In JSONC, it splices the target node's text. In TOML, it replaces the line range of the target table or field. Every other byte stays. After the edit, it parses the result again and compares it with the intended value. If the comparison fails, it refuses to write.
The tests for this are not about the happy path. They start with files that contain comments, trailing commas, unrelated tables, and the file's own quoting, then check that only the target entry changed.
The extension model
Each agent is an extension. It declares what assets it accepts and where it writes them. The page does not contain agent paths.
For prompts, an extension registers places and forms: a global directory, a workspace directory, a command file, a rule, an instructions section. The page renders the forms the extension declares. Adding an agent means shipping an extension, not editing the hub's prompt code.
The extension contract is in docs/extensions.md. Extensions run in the page and are trusted; there is no sandbox. That is a deliberate trade for a local tool, and it is documented.
What is not there yet
- Only Claude Code and Codex integrations exist. Cursor, Windsurf, and others would need extensions.
- Builds are not code-signed. Windows SmartScreen and macOS Gatekeeper warn on first launch.
- The macOS build is arm64 only.
- First run starts with an empty library. There is no scan-and-import of existing configs yet.
Try it
Download from GitHub Releases, or run the standalone CLI:
./context-hub-linux-x64
The source requires Node.js 20 and pnpm:
pnpm install
pnpm dev
Repo: https://github.com/bb-boy680/context-hub
MIT licensed. I would like feedback on the extension contract and on the first-run experience. If you point it at a workspace with existing agent configs, I want to know what it gets wrong.
Top comments (0)