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

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.

Start with the bundled codex-app-tools manifest and ~/.codex/config.toml entries described in the report, then trace how per-tool MCP approval modes and PermissionRequest decisions reach the Windows Desktop modal. Reproduce with create_thread or send_message_to_thread after a full restart; done means the documented override or an equivalent persistent setting suppresses prompts for the selected thread tools while unrelated tools remain configurable.