OpenClaw’s Codex Approval PR Turns MCP Elicitation Into a Real Human-Control Boundary
Approval buttons are not glamorous infrastructure. That is why they matter.
OpenClaw PR #92625 adds an on-request mode for Codex plugin destructive actions, bridging Codex app-server MCP elicitation into OpenClaw’s own interactive approval flow. The immediate demo is charmingly absurd — a Google Calendar event called “Walk lobster” — but the architecture is serious: when an embedded Codex connector wants to perform a write, OpenClaw can now pause the run, put an approval card in Slack, wait for Allow Once, and only then execute the action.
That is the right boundary. If Codex is going to live as one runtime inside a broader OpenClaw orchestration stack, it should not bring a separate trust model in through the side door. Destructive actions need to inherit the platform’s human-control plane, not improvise their own UX every time an MCP server asks for permission.
The useful part is not the button. It is where the button lives.
The PR is not tiny: 644 additions, 50 deletions, and 15 changed files. It expands codexPlugins.allow_destructive_actions with a third posture: on-request, sitting between always-allow and always-deny. The proof run used Codex’s native Google Calendar plugin and showed OpenClaw posting “Plugin approval required” into Slack with Allow Once, Allow Always, and Deny. After the one-time approval, the system created an event from 2026-06-12T23:30:00-07:00 to 2026-06-13T00:00:00-07:00.
The tests are the other signal: five files, 177 tests, covering Codex app-server config parsing, elicitation bridge behavior, plugin thread config, session binding, and activation defaults. That matters because approval bugs rarely fail as clean “no” responses. They fail as mismatched sessions, stale state, wrong channel delivery, or prompts that ask the wrong person to approve the right action. A calendar event is a toy example; a GitHub write, cloud mutation, ticket closure, or database operation is not.
The broader context is MCP elicitation. The MCP 2025-06-18 spec lets servers send elicitation/create requests during other MCP features. That is powerful: a tool can ask for missing structured input without breaking the flow. It is also dangerous: a server that can ask questions mid-run can shape the operator’s decisions, request fields, and create permission moments that look like normal conversation. The spec warns servers must not use elicitation to request sensitive information, and that applications should show the requesting server clearly, allow review or modification, and support decline/cancel paths. Translation: the client application is part of the security model.
Codex migration is really a governance migration
Most Codex-vs-Claude-Code comparisons still over-index on coding quality. That is understandable but incomplete. Once these tools become connectors inside an agent platform, the comparison shifts. Can the agent write to external systems? Can it request permission in the right place? Is the approval tied to a session? Is the audit trail visible to the people affected by the action? Can the operator distinguish a suggestion from an executed write?
OpenClaw’s design choice here is the important bit: Codex does not get to be its own island. Its MCP elicitation requests are translated into OpenClaw’s plugin approval system. That centralization is not bureaucratic; it is how operators keep a mental model. A team should not need one approval vocabulary for Codex, another for Slack plugins, another for GitHub MCP servers, and another for calendar connectors. That way lies “control plane by vibes,” which is exactly as stable as it sounds.
There is a practical posture recommendation here. If you run Codex through OpenClaw and have write-capable native plugins, on-request should be the default until you can justify something else. always-allow is fine for a local toy environment and reckless in a shared workspace. always-deny is safe but turns agents into elaborate autocomplete. on-request is the boring middle: the model can plan, the connector can ask, and the human approves at the point where authority is exercised.
That point matters more than people admit. “Human in the loop” is often used as a decorative phrase, but the actual question is: which loop? Reviewing a summary after an action is not the same as approving the action before it happens. A Slack approval card bound to the originating session is a stronger primitive because it keeps the decision near the work, near the requester, and near the audit record.
Approval UX does not fix overbroad authority
This PR is a good move, not a complete security story. An approval button cannot compensate for overbroad OAuth scopes, unclear plugin identity, weak token storage, or MCP servers that ask for information they should never request. Secure Code Warrior’s readout of NSA MCP guidance lands in the same territory: access control, prompt handling, tool execution, agent permissions, auditability, and third-party integration governance all have to work together. Approval is one layer in that stack.
The engineering implication is that agent platforms should treat write actions as first-class security events. The runtime should know which server requested the action, which connector would execute it, what scopes are involved, which session originated it, who approved it, and whether the approval was single-use or persistent. Without that metadata, approval becomes a modal dialog with better marketing.
The editorial take: this is a better Codex migration story than another leaderboard table. Code quality matters, but the platform that wins serious usage will be the one that routes authority through understandable, auditable boundaries. OpenClaw’s on-request bridge is not flashy. It is the kind of plumbing that lets teams say yes to agents without quietly saying yes to everything agents can reach.
Sources: OpenClaw PR #92625, MCP elicitation specification, GitHub App permissions reference, Secure Code Warrior analysis of NSA MCP guidance