Provide an app-server opt-out for request_user_input_async without replacing the model catalog

Request

Please provide an app-server configuration opt-out for the native
request_user_input_async tool, independently of a model's capability catalog.

The existing tools.experimental_request_user_input.enabled=false setting
disables request_user_input, but does not remove request_user_input_async.
An embedding host can own its user-question UI without wanting to replace
Codex's complete model catalog or disable unrelated execution tools.

This is a tool-exposure policy request, not a request to remove asynchronous
questions from clients that support them.

Verified environment and reproduction

• macOS arm64, installed codex-cli 0.153.2.
• Real codex app-server launched with a separate temporary home, Codex home,
  and XDG directories for each configuration.
• A credential-free loopback Responses endpoint captured the actual outgoing
  tools payload and returned a fixed final response. No real model request or
  model-directed tool execution was performed.
• A fixture catalog retained the binary's bundled Astra tool declarations,
  ["send_user_message_async", "clock"]. The catalog was byte-identical across
  all runs; only the app-server configuration flags changed.
• Tested both default and plan collaboration modes.

The same result occurred in both modes (eight captured requests).
exec_command, write_stdin, apply_patch, view_image, clock tools and web
search remained exposed; the requests' parallel_tool_calls value remained true.

Source-level explanation

In the
0.153.2 tool registration,
the synchronous registration checks
turn_context.config.experimental_request_user_input_enabled, while the
asynchronous registration separately checks the root-thread condition and the
catalog's request_user_input_async / send_user_message_async entries.
The send_async_message feature flag is marked removed.

The same independent registration conditions are present in
main at 553df1c.
That main revision was source-inspected, not executed.

Desired behavior

An embedding application should be able to disable structured native questions
at process startup without editing model metadata, changing user configuration,
or relying on prompt instructions that tell the model not to use an exposed tool.

Possible approaches for maintainers to consider:

• Make the existing experimental user-input opt-out cover both question tools,
  with backward-compatibility implications documented; or
• Add a separate explicit asynchronous-question opt-out.

Whichever interface is chosen should omit the disabled tool from the
model-visible tool list and keep unrelated tools and model metadata unchanged.
This request does not propose disabling general parallel tool execution,
background commands, or the separate free-form send_message_to_user_async
tool.

Related reports

• #43753: async request accepted but options are only visible as plain text.
• #43803 and #43057: unanswered async question UI disappears.

Those are UI-lifecycle reports, not necessarily the same root cause. They
illustrate why hosts need explicit control over whether they expose this
interaction before their UI supports it. The present request is specifically
about a configuration-level opt-out, and does not claim to fix those clients.

I searched the tracker for the async tool names, the experimental user-input
setting, and combinations with "disable"; I did not find an existing request
for this specific opt-out. Following the contribution policy, this is an issue
with reproduction evidence and a proposed boundary, not an external code PR.

Start in codex-rs/core/src/tools/spec_plan.rs, comparing the synchronous and asynchronous registration conditions and tracing the existing experimental user-input configuration. Add focused coverage for the selected app-server opt-out. Done means request_user_input_async is absent from the model-visible tools while unrelated tools and model metadata remain unchanged.