Windows: request_user_input_async returns accepted but renders only plain-text options without interactive controls #43753

What version of Codex CLI is running?

codex-cli 0.153.4, confirmed with codex --version on the affected machine.

What subscription do you have?

Not collected.

Which model were you using?

Not independently verified from client status.

What platform is your computer?

Windows 10 Pro, version 10.0.19045, x64. The affected UI shows a CLI/TUI-style conversation transcript. The exact terminal emulator and any separate frontend/app-server version were not collected.

What issue are you seeing?

During an active conversation, the assistant invoked the native request_user_input_async tool with a question and two options. The tool returned:

{"accepted":true}

The user did not receive an interactive selection/submission interface. Their screenshot shows the question and options rendered as ordinary transcript text. Translated excerpt:

Unity is currently in Play Mode and the new tool is not registered.
Should we end the run now, let the Editor load the new tool, and verify read-only calls?

- Preserve the current run; load later
- End the run and load now

The assistant continued working after the accepted response. The user then reported that no question interface had appeared and supplied the screenshot demonstrating the plain-text presentation. No structured answer to this asynchronous question arrived in the assistant's tool results.

What steps can reproduce the bug?

Observed sequence in this conversation, not yet independently reproduced in a clean session:

1. Use Codex on Windows with request_user_input_async exposed.
2. During an active turn, invoke it with a question and two choices. The actual call was:

{
  "questions": [
    {
      "title": "Unity 目前正在 Play Mode，新工具尚未注册。是否现在结束运行，让 Editor 加载新工具并验证只读调用？",
      "options": [
        "保留当前运行，稍后加载",
        "现在结束运行并加载"
      ]
    }
  ]
}

3. Observe the tool returning {"accepted":true} immediately.
4. The assistant continues working, while the user sees the question and choices only as plain transcript text, without selectable controls or a submit action.

The issue was reported while the assistant turn was still active; it was not first noticed after final completion. No tab switching was reported as a trigger.

What is the expected behavior?

A supported asynchronous structured question should present an actionable question UI and deliver the user's submitted answer back to the active conversation. If this client cannot render/handle that interaction, the tool should report the unsupported capability or provide an explicit usable fallback instead of silently returning accepted with only plain text.

accepted is understood to mean request acceptance, not user approval; the missing interactive interface is the issue being reported.

Additional information

• An earlier synchronous request_user_input call in this conversation successfully returned a structured answer.
• As a workaround, a separate desktop-question MCP tool successfully presented a question and returned the user's selected option. This does not establish the native tool's root cause.
• Related: Codex desktop: pending question interface disappears after switching tabs and does not return #43057 reports a disappearing request_user_input_async interface after tab switching in the macOS desktop app. This report concerns Windows and plain-text presentation without a reported tab switch; it may or may not share a cause.
• The official changelog lists support for structured asynchronous questions when enabled by the model catalog: https://learn.chatgpt.com/docs/changelog
• Submitted at the affected user's explicit request. A text transcription is included instead of uploading the project-bearing screenshot or private session logs.

Codex doctor report

Not collected for this initial report. Version and OS were checked directly; reproduction frequency and frontend/server compatibility remain unverified.