›_ Codex Issues
Codex Issues / #40793

[Windows Desktop 26.820.60940] codex_app thread tools prompt on every call and ignore approval_mode override

Open 💬 3 comments Opened Aug 26, 2026 by Al-Umb

What version of the Codex App are you using?

  • Codex Desktop: 26.820.60940
  • Bundled CLI: codex-cli 0.150.0-alpha.8
  • Bundled plugin: codex-app-tools 0.1.3

What platform is your computer?

Windows x64, NT 10.0.26200.9168 (25H2).

What issue are you seeing?

After updating to Codex Desktop 26.820.60940, first-party codex_app thread-management tools unexpectedly require a separate modal approval on routine calls.

Observed prompts include:

Allow the codex_app MCP server to run tool "create_thread"?
Allow the codex_app MCP server to run tool "fork_thread"?
Allow the codex_app MCP server to run tool "send_message_to_thread"?

The same behavior affects handoff_thread.

This is a regression from previous Desktop behavior and blocks long-running multi-task coordination until the user manually clicks Allow once for each operation.

The bundled codex-app-tools 0.1.3 manifest as shipped contains a server default of approve, but overrides these thread tools to prompt:

{
  "default_tools_approval_mode": "approve",
  "tools": {
    "automation_update": { "approval_mode": "prompt" },
    "create_thread": { "approval_mode": "prompt" },
    "send_message_to_thread": { "approval_mode": "prompt" },
    "fork_thread": { "approval_mode": "prompt" },
    "handoff_thread": { "approval_mode": "prompt" }
  }
}

More importantly, the documented user override for plugin-provided MCP tools is accepted by the TOML parser but has no effect:

[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"

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

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

A PermissionRequest hook matching the canonical tool name (for example mcp__codex_app__send_message_to_thread) and returning an allow decision also does not intercept or suppress this Desktop MCP approval modal.

What steps can reproduce the bug?

  1. Run Codex Desktop 26.820.60940 on Windows with the bundled codex-app-tools 0.1.3 plugin enabled.
  2. Open or resume a task that coordinates another Codex task.
  3. Let the agent call send_message_to_thread, create_thread, fork_thread, or handoff_thread.
  4. Observe the modal approval request for the first-party codex_app MCP server.
  5. Add the per-tool approval_mode = "approve" overrides shown above to ~/.codex/config.toml.
  6. Fully exit Codex, including the tray/background process, and start it again.
  7. Repeat the tool call.

What is the expected behavior?

The documented per-tool plugin MCP approval override should be honored after a full application restart.

For first-party routine thread coordination, Codex should either:

  • restore the previous no-prompt behavior; or
  • provide and honor a persistent user setting that allows these specific tools without repeated confirmation.

It is reasonable for unrelated sensitive operations such as automation_update to remain independently configurable as prompt.

What actually happens?

The modal still appears and offers only Deny or Allow once. Every affected call pauses the active task and requires manual intervention.

Additional information

  • The application was fully restarted after the documented config override. A new codex.exe process started at 12:30:39; the approval modal reproduced at 12:31.
  • As a stronger isolation test, both active copies of the bundled manifest were directly changed to approval_mode: "approve" for all four thread tools at 12:35:18.
  • Codex was restarted again; the current codex.exe started later at 12:48:08.
  • At 12:53, the existing task still prompted for create_thread.
  • A completely fresh task (01a03c6a-6eff-7453-86bc-6684fb2e722c) then prompted on its first send_message_to_thread call.
  • Therefore this is not limited to cached policy in tasks created before the configuration change.
  • The task/model itself cannot reliably report whether a Desktop-side approval modal appeared. After the user clicks Allow once, the model sees only a successful tool result. The Desktop UI is the approval oracle.
  • No repository-specific code, external MCP server, or custom transport is involved. These are first-party Desktop task-management tools.
  • A direct local edit of the bundled manifest is not a durable workaround because app/plugin updates can replace the cached manifest—and in this reproduction it was not effective even after restart.

Related but not duplicate: #15437, #20289, #25810, and #40715.

View original on GitHub ↗

3 Comments

Al-Umb · 2 days ago

Additional reproduction after applying the direct bundled-manifest fallback:

  • Both active copies of codex-app-tools/desktop-mcp.json were last written at 12:35:18 and contained approval_mode: "approve" for:
  • create_thread
  • send_message_to_thread
  • fork_thread
  • handoff_thread
  • The currently running codex.exe process started later, at 12:48:08.
  • At 12:49, the same existing task again displayed:
Allow the codex_app MCP server to run tool "send_message_to_thread"?

So this reproduction is not explained by the process simply predating the manifest edit. The current build is either obtaining the approval policy from another source, ignoring these manifest values, or preserving the policy in existing task state.

This was still reproduced in an existing task, so per-task policy caching remains a plausible narrower cause. A fresh-task A/B test would be useful to distinguish that from a globally ignored manifest/config override.

Al-Umb · 2 days ago

Correction: fresh task also prompts

The conclusion in the previous version of this comment was incorrect. UI screenshots provide the authoritative result:

  1. The existing diagnostic task displayed:

``text
Allow the codex_app MCP server to run tool "create_thread"?
``
while creating the clean test task.

  1. The newly created task 01a03c6a-6eff-7453-86bc-6684fb2e722c then displayed:

``text
Allow the codex_app MCP server to run tool "send_message_to_thread"?
``
for its first and only diagnostic tool call.

Therefore the bug does reproduce in a completely fresh task. It is not limited to an existing-task policy cache.

The new task later reported that no manual approval was requested, but that statement is not a valid oracle: the task/model cannot observe the Desktop-side modal. After the user approves once, the tool result simply appears to the task as a normal successful completion. The Desktop UI screenshot is the reliable evidence for whether approval was requested.

Combined evidence:

  • Both active bundled manifest copies contained approval_mode: "approve" for the four thread-management tools at 12:35:18.
  • The current codex.exe process started later at 12:48:08.
  • create_thread prompted in the existing task at 12:53.
  • send_message_to_thread prompted on its first call in the newly created task at 12:53.

Conclusion: Desktop 26.820.60940 is ignoring or overriding both the documented plugin configuration and the effective bundled-manifest approve values for these first-party codex_app approval modals.

sryuta0322-debug · 1 day ago

Additional Windows reproduction, with user authorization to report. Desktop 26.820.60940, bundled CLI 0.150.0-alpha.8, bundled codex-app-tools 0.1.3.

Observed locally:

  • Retained app-server logs show Desktop 26.814.41957 through Aug 26 17:24 JST and 26.820.60940 from 18:06 JST. Task execution records changed from the dynamic codex_app__send_message_to_thread route to mcp__codex_app.send_message_to_thread. Multiple tasks then recorded codex_app mcp_tool_call_approval / ResolveElicitation Accept around 18:35. These are retained observations, not a complete historical count or proof of the exact update instant.
  • Both send_message_to_thread and automation_update repeatedly prompt. automation_update read/view and management calls also contributed to the interruption count.
  • The documented plugin-scoped overrides for these two tools are present in config.toml with approval_mode = "approve". After the user exited and restarted the desktop app, a necessary internal send still displayed Allow once, which the user clicked. A matching ResolveElicitation Accept was logged on Aug 27 at 01:14:30 JST. A later necessary send reproduced it again.
  • Read-only inspection of the desktop MCP catalog shows codex_app with pluginId=null. Standalone codex mcp list --json using the actual CODEX_HOME lists node_repl but not codex_app. This suggests a desktop-injected registration/policy path distinct from the plugin override, but we have not verified the effective policy source or precedence.

No bundled manifest edits, private IPC calls, approval auto-clicking, or global sandbox/approval relaxation were used in this reproduction. No private task text, personal paths, credentials, or raw logs are attached.

Could maintainers confirm the supported persistent per-tool approval setting for the desktop-injected codex_app server, whether the documented plugin override should apply, and how to inspect/reload its effective policy? If this is a regression, a fix or supported workaround limited to the affected internal tools would unblock unattended task coordination. Successful tool completion after Allow once must not be treated as proof that no prompt appeared.