MCP hook

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #17930

Powered by Codex Action

Can you say more about what functionality you're looking for? What do you mean by "MCP related hooks"?

You may be interested in this documentation.

@etraut-openai Thanks for your reply💗.

We use these two MCP related hooks in the cursor mainly to determine whether the code generated by AI belongs to a certain MCP service, report data through custom scripts, and evaluate the generation effect of the code. Therefore, we need to know the timing of calling the MCP service.

MCP related hooks refer to the hooks related to MCP service calls, such as the beforeMCPExecution hook and afterMCPExecution hook in cursor.

The document for codex states 'don't intercept MCP, Write, WebSearch, or other non shell tool calls', so I would like to know if there are any plans to support MCP related interception in the future.

We generally prioritize features based on community input (upvotes). This is the first request we've received for this feature. We'll see if it gets upvotes.

@etraut-openai Got it, Thanks for your reply🫶.

Indexed this hook ticket in the umbrella tracker: #21753

Goal: collect the scattered Codex hook requests and bugs into one parity matrix for Full Claude Code Hook Parity (29+), while preserving this issue as the detailed thread for its specific behavior.

The shape Sirros is asking about, hooks that fire specifically on MCP tool calls, is already partly in Codex today, just not advertised that way.

Codex's existing [[hooks.PreToolUse]] and [[hooks.PostToolUse]] blocks fire for MCP-served tools too, not just built-in ones. The tool_name in the hook payload arrives prefixed (for example mcp__<server>__<tool> after the MCP_TOOL_NAME_DELIMITER = "__" join in codex-rs/codex-mcp/src/mcp/tools.rs), so the matcher regex ^mcp__myserver__ is the documented way to scope a hook to a specific MCP server without a new hook type.

For Sirros's data-reporting use case (which MCP server, which tool), one PostToolUse hook with a matcher = "^mcp__" block and a Python or Node shim that splits the prefix at __ covers it. I wired exactly this pattern for v0.7.5 of world-model-mcp's Codex adapter. Both adapter PreToolUse and PostToolUse helpers read the standard Codex payload (session_id, turn_id, tool_name, tool_input) and route on the prefix without needing any MCP-specific event.

Two things that would benefit from official MCP-aware hooks, beyond what the existing hooks already do:

1. A McpServerStart and McpServerStop event surface. Today, MCP server lifecycle status is exposed via the app-server protocol (PR #24698) but not via the hook surface. If a server fails its startup handshake or crashes mid-session, a hook cannot react. This is the kind of observability Sirros's eval-reporting use case would benefit from.

1. A tool_input_intercept mode on PreToolUse that exposes the MCP server's tool schema, so a hook can know that "this Bash call is via mcp__shell__exec and the schema expects cmd: string," not just "the name happens to start with mcp__." The current shape is sufficient for matching, but schema-aware intercepts would unlock richer policy.

Adapter repo with the prefix-routing pattern wired: https://github.com/SaravananJaichandar/world-model-mcp/tree/main/adapters/codex

Cross-agent reference: agent-manual (https://github.com/Ar9av/agent-manual) documents how Claude Code and Gemini CLI wire MCP into their hook systems today, which might be useful while this matures in Codex.

Claude Code uses mcp_tool as a first-class hook type — a hook can call a tool on a connected MCP server directly (not just run a shell command). Hook matchers also support MCP tool notation: mcp__<server>__<tool> so you can target e.g. mcp__github__create_issue specifically in a PreToolUse rule.

Gemini CLI takes a slightly different approach — MCP tools show up in BeforeTool/AfterTool hooks like any native tool, but the stdin payload includes mcp_context and original_request_name fields so you can tell them apart programmatically.