Codex CLI Plugins: Install, Inspect, and Use Them

Codex CLI plugins are tool definitions that extend what the assistant can do beyond answering in chat: shell commands, MCP server connections, and configured scripts the CLI can call during a task. When a plugin is active, the assistant can run tests, read files, or call an external service without you copying output into the chat by hand.

Knowing what a plugin can and cannot do before you install it saves problems later. A plugin with write access to your project folder deserves more scrutiny than one that only reads from a read-only API. Tools like fenbs keep the shared instructions and project context that connected assistants rely on, separate from the plugins themselves.

What a Codex CLI plugin is

A plugin is a configuration entry that tells the CLI about a command or a server. The assistant sees a named tool with a description; when it decides that tool is needed for the current task, the CLI calls the command and feeds the output back. You define which tools are available through the CLI's configuration file, and the assistant cannot use a tool that is not listed there.

Two main kinds exist. A shell tool wraps a command you already have: a linter, a test runner, or a script that returns structured text. An MCP server is a separate process that speaks the Model Context Protocol and lets the assistant read and update resources in an outside service. The same MCP server can be shared across several AI apps if each is configured to reach it.

Codex CLI skills, hooks, and worktree features are related but separate — see Codex CLI skills, Codex CLI hooks, and Codex CLI worktree for those.

Where plugin configuration lives

The CLI reads its configuration from a file in your home directory, typically inside a .codex folder. That file holds the tools and MCP servers section. Each entry gives the tool a name the assistant uses to identify it, a description it uses to decide when to call it, and the command or server address to reach.

If the file does not exist yet, the CLI creates a default on first run. You can also point the CLI at a different configuration file at startup, which lets you keep separate setups for different projects without changing your global defaults.

See Codex CLI commands for the flags available at startup, including how to pass a non-default configuration path. For platform-specific paths on Windows, see Codex CLI on Windows.

How to install a plugin

1. Read the plugin's documentation. Note what command or server address it provides, what arguments it takes, and what access it needs on your machine or network.
2. Open your Codex CLI configuration file. Find the tools or mcpServers section, or add one if it is not there yet.
3. Add an entry with a name, the full command path or server address, any required arguments, and a description specific enough for the assistant to know when to call it.
4. Save the file and restart the CLI. Run a simple task that should use the new tool and confirm the output matches what you expected.
5. Review the first several uses before expanding what the tool can access. If the assistant calls it when it was not needed, narrow the description and test again.

Check what a plugin can do before you run it

Read the plugin's source if it is available, or its documentation if not. The important questions are: which file paths does it read or write, what network calls does it make, and what data does it send to external services?

• Read access: can the plugin see files outside the current project folder?
• Write access: can it create, modify, or delete files?
• Network calls: does it contact external servers, and which ones?
• Data sent: does it forward your code, prompts, or outputs to a remote service?
• Tool-call approval: does the CLI prompt you before calling the tool, or does it call automatically?

Shell tools inherit the permissions of the user running the CLI. A tool with write access to your project folder can change any file in it. Treat each plugin as a program you are choosing to run with your own access level. The CLI's approval mode controls whether the assistant calls tools without a per-call confirmation. Start with approval prompts on for any new plugin. See Codex CLI best practices for guidance on safe defaults.

Test a new plugin with a narrow task first

Give the newly added plugin one limited task and check the result. If the plugin is a test runner, ask the assistant to run a single test file and show the output. If it connects to a code repository, ask it to list the contents of one directory.

Compare the output to what you expected. If the assistant calls the tool when it was not needed, the tool's description is probably too broad: tighten it and test again. Problems that only appear with large files or slow connections are easier to catch in low-stakes tests than after you have built a workflow that depends on the plugin.

How to do this with fenbs

Plugins extend what Codex CLI can do in a session, but they do not carry the project's goals, approved rules, or saved progress from one session to the next. Fenbs holds that context separately so any connected assistant can pick up work in the right state.

1. Create a free account and add your project to a kanban board.
2. Connect Codex CLI to fenbs over MCP from /integrations. The fenbs MCP server works alongside your other plugins in the same configuration file.
3. Add your plugin usage rules as Decisions and rules. If a test plugin must run before any code change is marked done, record that as a standing rule.
4. At the start of each session, ask the assistant to read the fenbs context for the project. It will see the rules, where the work was left, and any notes from earlier sessions.
5. Before you stop, ask the assistant to save progress: what it completed, what it tested, and what the next step is.

For running parallel workstreams, see Codex subagents. For a comparison of Codex CLI with the web app and IDE extension, see Codex app vs CLI vs IDE extension.