# fcakyon/claude-codex-settings: shared Claude Code, Codex and Cursor plugins with hooks and guardrails

> A plugin marketplace that ships the same skills, commands and hooks to Claude Code, Codex CLI, Cursor and Gemini CLI, plus a CLAUDE.md file you symlink into every agent. The interesting part is the enforcement layer, not the prompt library.

**fcakyon/claude-codex-settings** — Battle-tested Claude Code, OpenAI Codex, Cursor configs, plugins, hooks and agents with Kimi, MiniMax and GLM API support.

- Repository: https://github.com/fcakyon/claude-codex-settings
- Website: https://claudesettings.com
- Stars: 1,162 · Forks: 109
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/fcakyon-claude-codex-settings

## The problem: four coding agents, four rule sets, one team

If a team uses Claude Code, Codex CLI, Cursor and Gemini CLI, the guidance each agent follows drifts apart. Someone writes a good CLAUDE.md, someone else rewrites it as AGENTS.md for Codex, a third person copies fragments into Cursor rules, and within a month the three files disagree about commit message format, code review expectations and how much abstraction is acceptable. The repository's own framing of the problem is a Karpathy quote about agents that "make wrong assumptions on your behalf", "don't seek clarifications" and "bloat abstractions". The maintainer states the guidelines are structured to fix exactly those pitfalls. That is the target audience: teams running more than one agent on the same codebase, and individuals who switch between Claude Code and Codex depending on the task. The project does not try to make the agents smarter. It tries to make them follow the same written rules, and in one case it enforces a rule with a hook rather than a paragraph.

## One marketplace, four install paths, one shared CLAUDE.md

The architecture is a plugin marketplace. The repository root holds a plugins/ directory plus per-tool manifests: .claude-plugin/, .codex/, .cursor-plugin/ and .agents/. Each plugin lives under plugins/<name>/ and carries a skills/ directory with a SKILL.md, and in some cases a hooks/ directory with Python scripts. Installation differs per tool because the CLIs differ: Claude Code and Codex CLI add the repository as a marketplace and then install by name, Gemini CLI installs from a local path, and Cursor uses cursor-agent with an interactive /plugin command. The unifying mechanism is the guidance file. .claude/CLAUDE.md is described as the file written for your projects, and the README suggests symlinking it so every tool reads the same content: AGENTS.md for Codex CLI, Cursor and Copilot, GEMINI.md for Gemini CLI. That symlink trick is the load-bearing idea. Without it, the plugin install just distributes skills; with it, all four agents read identical instructions, and editing one file updates all of them. The README also mentions a /claude-tools:sync-claude-md command that pulls the file into ~/.claude/CLAUDE.md, which covers the global-config case rather than the per-project one.

## Installing the marketplace and running /simplify for the first time

The README points to INSTALL.md for prerequisites before anything else, so read that file first; the README itself does not list the required tool versions. For Claude Code, adding the marketplace is a one-time step, then any plugin installs by name. The example below uses the simplify plugin, which is the one with the most visible behaviour. After the install completes, the plugin's skill is available as /simplify, which reviews your staged or committed diff across four angles (reuse, simplification, efficiency, altitude) with parallel agents and then applies the cleanups.

```bash
# Add marketplace (one time)
claude plugin marketplace add fcakyon/claude-codex-settings

# Install any plugin by name
claude plugin install simplify@claude-settings
```

## Codex CLI and Gemini CLI take different commands for the same plugin

The same simplify plugin installs into Codex CLI through a marketplace add followed by a plugin add, and into Gemini CLI by pointing at the plugin directory inside a checkout. Note that the Gemini form references ./plugins/simplify, so it expects the repository to be present locally rather than fetched from a marketplace.

```bash
# Add marketplace (one time)
codex plugin marketplace add fcakyon/claude-codex-settings

# Install any plugin by name
codex plugin add simplify@claude-settings

gemini extensions install --path ./plugins/simplify
```

## Sharing one CLAUDE.md across Codex, Cursor and Gemini

After installing a plugin, the second step is the shared guidance file. The README offers two routes: run /claude-tools:sync-claude-md to copy it into ~/.claude/CLAUDE.md, or paste it into a project as CLAUDE.md and then point the other tools at the same file. The symlink approach keeps a single source of truth per project; use relative targets so the links survive a clone.

```bash
ln -sfn CLAUDE.md AGENTS.md # Codex CLI, Cursor, Copilot
ln -sfn CLAUDE.md GEMINI.md # Gemini CLI
```

## The hooks are the part that actually enforces anything

Two plugins in the README ship hooks, and both change behaviour rather than suggesting it. The simplify plugin includes hooks/scripts/guard.py, which the README says requires a completed /simplify run before each Claude Code or Codex commit, unless you explicitly ask to skip it for one commit. That is a real constraint on commit flow, and it is the clearest example of the project's philosophy: a rule that matters belongs in a hook, not in a paragraph the model may or may not follow. The humanize plugin takes the opposite approach to the same idea, scanning text before a Write or Edit saves and blocking whatever reads like machine-written prose. Its rules are specific: three marks (the em-dash, section sign and stray semicolon, with the en-dash explicitly allowed), 53 stock words such as leverage and seamlessly each mapped to a plain swap, 16 openers and cliches, and 10 pile-up words flagged at three or more uses in a single write. It reads Markdown files whole and checks comments and docstrings in code files while skipping source code. The README states humanize runs on Claude Code and Gemini, not on Codex. That asymmetry is worth knowing before you standardise on it.

## Where this is the wrong tool

The simplify plugin reviews changed-code quality, not correctness bugs. The README says so directly. If your problem is that the agent writes subtly wrong logic, /simplify will not catch it, and the guard.py hook will still block your commit until the review runs, which turns a quality tool into a speed bump on a bug hunt. The humanize plugin is narrower still: it rejects a fixed vocabulary list, so it will not stop a model from writing a fluent paragraph that says nothing, only from using the specific words on the list. And the whole repository assumes you are already running at least one of these agents with a plugin system. If you use a single tool and are happy with its defaults, installing a marketplace to get one skill is more moving parts than the problem deserves. The README also does not document rollback or uninstall steps for any of the four install paths, and it does not describe what happens when a hook fails or when the Python script cannot run, so plan to test the hooks on a scratch repository before letting guard.py near a shared branch.

## Compared with hand-rolled dotfiles or a single-tool config repo

The obvious alternative is keeping your own dotfiles repository with a CLAUDE.md, an AGENTS.md and a .cursor/rules directory, copied or symlinked by hand. That gives you total control and no third-party code in your commit path. The difference in approach is enforcement. A hand-rolled config is advisory: the model reads it and may drift from it. This project ships Python hooks that run at write time and at commit time, which is a different category of guarantee, at the cost of trusting someone else's script and vocabulary list. A second alternative is a single-tool configuration repository, for example one that only targets Claude Code. That is simpler and has no cross-tool symlink to maintain, but it leaves Codex CLI and Cursor users on the team without the same rules, which is precisely the drift this project exists to remove. The trade-off is real in both directions: this repository buys consistency across four agents and pays for it with more install paths, more manifests and two hooks that can interrupt your workflow.

## Conclusion

Adopt it if you already run two or more of Claude Code, Codex CLI, Cursor and Gemini CLI and are tired of maintaining a separate prompt and rule set for each, or if you want a commit-time check that a diff was reviewed before it lands. Skip it if you use one tool only, since the cross-tool duplication is the whole value proposition, and skip it if you want a prompt library rather than enforcement. Before installing, read INSTALL.md for the prerequisites the README defers to, and check whether the guard.py commit hook fits your workflow, because it blocks commits until /simplify has run unless you explicitly skip it for one commit.

## FAQ

### What are the best settings to use in Codex?

The repository does not rank settings. It ships plugins you install by name through codex plugin add, plus a shared CLAUDE.md that you can symlink to AGENTS.md so Codex CLI reads the same guidance as the other tools. Which plugins to install depends on whether you want the review flow, the writing checks or both.

### How to setup Claude code with Codex?

Install the plugins separately in each tool, since Claude Code uses claude plugin install and Codex CLI uses codex plugin add, then link the guidance file with ln -sfn CLAUDE.md AGENTS.md so both agents read the same rules. The README also offers /claude-tools:sync-claude-md to pull the file into ~/.claude/CLAUDE.md.

### How do I configure Claude Code settings?

The repository treats configuration as two layers: plugins installed from the marketplace, and a CLAUDE.md guidance file that you either sync into ~/.claude/CLAUDE.md or paste into a project. The README defers prerequisites to INSTALL.md rather than listing them inline.

## Sources

- [fcakyon/claude-codex-settings on GitHub](https://github.com/fcakyon/claude-codex-settings)
- [License: Apache-2.0](https://github.com/fcakyon/claude-codex-settings/blob/main/LICENSE)
- [Project website](https://claudesettings.com)
- [README](https://github.com/fcakyon/claude-codex-settings/blob/main/README.md)
- [Releases](https://github.com/fcakyon/claude-codex-settings/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fcakyon-claude-codex-settings