bug: Codex adapter does not handle item/permissions/requestApproval, causing injected MCP tools to be rejected

[jeksmith]

What's broken

What I am trying to accomplish

I want to use Codex from within an existing Paseo workspace to create or launch additional Paseo workspaces, worktrees, and agents. For example, I want an agent working in one workspace to start reviewer agents in adjacent lanes, either in new worktree workspaces or in current/detached workspaces that share the current workspace context.

The natural interface for this appears to be Paseo’s injected MCP tools, such as create_agent, create_worktree, list_agents, wait_for_agent, and get_agent_activity.

Summary

When running Codex through Paseo, injected Paseo MCP tools can fail immediately with:

user rejected MCP tool call

The local Paseo daemon endpoint itself is healthy and works when called directly. The failure appears to happen before the MCP request reaches the daemon.

The likely cause is that newer Codex app-server versions emit item/permissions/requestApproval for request-permissions / MCP approval flow, but Paseo’s Codex adapter does not currently register a handler for that app-server request method.

Environment

• Paseo Desktop / daemon: 0.1.99
• Codex CLI: codex-cli 0.142.0
• Provider: Codex
• OS: macOS

Reproduction

1. Start a Codex agent in Paseo with the injected internal Paseo MCP server available.

2. Have the agent call an injected Paseo MCP tool, for example mcp__paseo.list_worktrees.

3. Observe the tool result:

   user rejected MCP tool call

4. Call the same local daemon MCP endpoint directly with the injected bearer token and callerAgentId.

Direct MCP calls succeed, including tools/list and tools/call.

Expected behavior

Paseo should surface or resolve Codex’s item/permissions/requestApproval request the same way it does for command/file approvals, then return a valid PermissionsRequestApprovalResponse to Codex so the MCP tool call can proceed or fail with a clear user-visible denial.

Actual behavior

The injected MCP tool call fails immediately with:

user rejected MCP tool call

In Codex session logs, the MCP tool call ends at zero duration with that error, suggesting Codex/Paseo rejects before sending the MCP request to the daemon.

Evidence from current Paseo main

packages/server/src/server/agent/providers/codex-app-server-agent.ts currently registers handlers for command execution approval, file change approval, and tool user-input requests, but not:

item/permissions/requestApproval

Source:
https://github.com/getpaseo/paseo/blob/main/packages/server/src/server/agent/providers/codex-app-server-agent.ts

Codex 0.142 includes item/permissions/requestApproval, PermissionsRequestApprovalParams, and PermissionsRequestApprovalResponse in its app-server protocol.

Suspected fix

Add support for item/permissions/requestApproval in the Codex app-server adapter.

This may require more than adding one handler registration, because Paseo’s app-server transport currently appears to pass only params to handlers. For permissions requests, preserving the JSON-RPC request id may be necessary so Paseo can respond to the correct server request.

Potential implementation shape:

• Extend the app-server transport request handler signature to include the JSON-RPC request or request id.
• Register item/permissions/requestApproval.
• Map the request into Paseo’s permission UI/model.
• Resolve it back to Codex with a valid PermissionsRequestApprovalResponse.
• Add a regression test alongside the existing command/file approval request handler tests.

Related issues

This appears adjacent to, but distinct from:

• Codex app-server approval prompts hang indefinitely in Paseo UI #855, older Codex approval prompt hang fixed in 0.1.72
• Codex Auto-review permission mode: full implementation #960 / feat(codex): implement Auto-review permission mode #963, Codex auto-review permission mode

Steps to reproduce

1. Start a Codex agent in Paseo with the injected internal Paseo MCP server available.

2. Have the agent call an injected Paseo MCP tool, for example mcp__paseo.list_worktrees.

3. Observe the tool result:

   user rejected MCP tool call

4. Call the same local daemon MCP endpoint directly with the injected bearer token and callerAgentId.

Direct MCP calls succeed, including tools/list and tools/call.

Where did this happen

Desktop (Electron)

Paseo version

0.1.99

OS version

MacOS 26.5.1

Agent provider

Codex

Provider configuration

Codex CLI v0.142.0 with OpenAI API

Logs

Codex session log excerpt:

{"timestamp":"2026-06-24T01:18:04.148Z","type":"event_msg","payload":{"type":"mcp_tool_call_end","call_id":"call_OUYkAtI1gwdVGTa0sejMjoNA","invocation":{"server":"paseo","tool":"list_models","arguments":{"provider":"claude"}},"duration":{"secs":0,"nanos":0},"result":{"Err":"user rejected MCP tool call"}}}

Screenshots or video

No response