mcp-codex-allowlist
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEX_HOME | No | The Codex home directory. The server reads direct *.rules files from the user Codex home and a project's .codex/rules/ directory. The default is ~/.codex. | ~/.codex |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_global_exec_rulesA | Read user rules from $CODEX_HOME/rules/*.rules (default ~/.codex). |
| get_local_exec_rulesB | Read rules from the project .codex/rules directory for trusted projects. |
| get_codex_exec_rulesB | Read user and project rule files with their source scope and paths. Files can contain allow, prompt, and forbidden rules. This tool does not compute effective policy from approval settings, sandbox settings, managed policy, or project trust. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
get_global_exec_rules and get_local_exec_rules are distinct scopes, but get_codex_exec_rules is effectively a superset that reads both, so an agent can often just call the aggregate and the other two become redundant. Descriptions help clarify scope differences, but the boundary between 'both scoped reads' and 'combined read' invites miselection.
All three follow the same snake_case get_<scope>_exec_rules pattern, with only the scope token varying (global/local/codex). Fully predictable.
Three focused read tools are reasonable for an inspection-only rules surface, though the combined tool makes the set feel slightly redundant. Nothing extraneous, but arguably two tools would suffice.
The surface is read-only: no tools to add, modify, or remove allow/prompt/forbidden rules, and effective policy computation is explicitly disclaimed. For an allowlist server, the absence of any write or policy-resolution operation is a significant gap that will block manage-allowlist workflows.