›_ Codex Issues
Codex Issues / #41167

Per-tool plugin approval_mode ignored for bundled codex-app-tools in Desktop 26.820.60940 / CLI 0.150.0-alpha.8

Open 💬 2 comments Opened Aug 27, 2026 by 2stndz8fty-droid
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

ChatGPT Desktop 26.820.60940, build 7119; bundled codex-cli 0.150.0-alpha.8; codex-app-tools@openai-bundled 0.1.3.

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

The documented per-tool plugin approval_mode configuration is accepted by strict configuration validation but ignored at runtime for the bundled codex-app-tools plugin.

Configuration used:

approvals_reviewer = "user"

[plugins."codex-app-tools@openai-bundled".mcp_servers.codex_app.tools.create_thread]
approval_mode = "approve"

[plugins."codex-app-tools@openai-bundled".mcp_servers.codex_app.tools.send_message_to_thread]
approval_mode = "approve"

After a full Codex Desktop restart, both create_thread and send_message_to_thread still generated an MCP approval elicitation. create_thread succeeded only after a human Accept decision. send_message_to_thread remained waiting for approval and failed after a human Decline decision. The strict configuration doctor reported that the configuration and bundled plugin loaded successfully.

The bundled desktop-mcp.json marks automation_update, create_thread, send_message_to_thread, fork_thread, and handoff_thread as prompt. The observed behavior indicates that the documented per-tool override is not applied before the Desktop/MCP approval gate.

What steps can reproduce the bug?

  1. Add only the two per-tool overrides shown above.
  2. Fully quit and restart Codex Desktop.
  3. Run the bundled CLI strict configuration doctor and verify that configuration and plugin loading succeed.
  4. Invoke create_thread.
  5. From the created local task, invoke send_message_to_thread back to the source task.

What is the expected behavior?

Only create_thread and send_message_to_thread run without an MCP approval prompt. automation_update, fork_thread, and handoff_thread continue to require approval as declared by the bundled plugin manifest.

Additional information

Actual behavior

Both configured tools still generate ResolveElicitation approval requests. create_thread succeeds only after human acceptance; send_message_to_thread waits for approval and fails when declined. No invalid or unknown configuration is reported.

Additional information

The plugin MCP proxy contains no separate approval logic; it forwards tool discovery and calls to the native host. Please apply the effectively merged per-tool plugin configuration before Desktop/MCP approval gating and expose diagnostics showing the effective approval_mode, configuration source, and precedence per tool.

No secrets, full conversations, repository contents, or raw private logs are included in this report.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 19 hours ago

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

  • #40793

Powered by Codex Action

chusia06 · 13 hours ago

Additional macOS A/B reproduction from a real multi-task review workflow.

Environment:

  • ChatGPT Desktop 26.820.60940 (build 7119)
  • macOS 26.5.2 (25F84), Apple Silicon
  • New bundled runtime: 0.150.0-alpha.8
  • Historical control runtime on the same host/account: 0.149.0-alpha.4.1

Observed regression:

  1. A historical independent reviewer task running 0.149.0-alpha.4.1 invoked send_message_to_thread four times. Every function call has a paired successful function_call_output; no approval boundary interrupted those callbacks.
  2. A fresh independent reviewer task running 0.150.0-alpha.8 was created in its own clean managed worktree at an exact detached commit.
  3. Ordinary read-only Git identity checks completed successfully inside that worktree.
  4. Its first send_message_to_thread callback recorded the function call but never produced a function-call output. Desktop exposed the task as activeFlags=["waitingOnApproval"] and showed the approval UI.
  5. The task was not reading or writing another task's worktree, did not use network access, and did not perform a destructive action. The approval was specifically attached to the first-party cross-task callback.

This rules out cross-worktree filesystem access as the trigger and gives a direct 0.149 -> 0.150 behavioral comparison for the same first-party tool.

The source coordinator was running with Full Access (approval_policy=never, disabled/danger-full-access sandbox). The created visible task still received managed on-request / approvals_reviewer=user / workspace-write, consistent with the related inheritance defect in #33282. In 0.150.0-alpha.8, the newly introduced task-messaging path then turns the internal callback into a user-blocking MCP approval.

Impact: unattended controller/reviewer or executor/controller workflows stop at every result callback, even though the user already authorized the overall local workflow. The current safe workaround is for the controller to poll/pull the child result with wait_threads, but that makes cross-task messaging asymmetric and defeats the intended callback workflow.

Expected behavior: create_thread should preserve the effective Full Access posture (or expose an explicit permission selection), and a user-approved per-tool approval_mode="approve" for send_message_to_thread should be applied before Desktop's MCP approval gate.

All task IDs, repository names, local paths, prompts, and private logs are intentionally omitted.