codex-tui subagents lose client identity and repeatedly emit unfulfillable plugin-install elicitations

[robobryce]

What version of Codex CLI is running?

codex-cli 0.144.5. I also verified the underlying routing bug against current main at fa1d4c40d0e63eef2e0ba8a9e004ccd0a80b77f5 and 0.146.0-alpha.14.

What subscription do you have?

Authenticated ChatGPT subscription; exact plan is not relevant to this local client-routing issue.

Which model were you using?

The issue is model-independent. It occurs when a child calls the built-in request_plugin_install tool.

What platform is your computer?

Linux 6.8.0-100-generic x86_64 x86_64

What terminal emulator and version are you using?

Codex CLI terminal UI (codex-tui). The terminal emulator is not material to the reproduction.

Codex doctor report

codex doctor --json produced no report in 0.144.5.

What issue are you seeing?

In a long-running multi-agent TUI session, GitHub-focused subagents repeatedly display requests to install the GitHub plugin. The request looks like user input is required, but accepting it or entering input does not install anything. The tool result can report:

{"user_confirmed":true,"completed":false}

The same request then reappears from later subagents or retries. In one affected thread lineage I observed 21 GitHub install calls; three accepted responses all returned completed:false.

This is not a normal request_user_input prompt. It is an mcpServer/elicitation/request generated by request_plugin_install with an empty form schema. The TUI has no plugin-install interstitial behind that form, so it cannot fulfill the request.

What steps can reproduce the bug?

End-user reproduction:

1. Run Codex CLI 0.144.5 in the terminal UI with multi-agent, apps, plugins, and tool suggestions enabled.
2. Ensure the recommended GitHub plugin is not installed.
3. Start a long-running task that delegates several GitHub-focused operations to subagents, such as asking Codex to investigate multiple GitHub issues or repositories concurrently.
4. Allow a child agent that receives <recommended_plugins> containing GitHub to call request_plugin_install.
5. Observe an install form/request appear in the parent TUI.
6. Accept the request or enter input. No plugin is installed; the result reports user_confirmed:true, completed:false.
7. Continue the session or spawn additional GitHub-focused children. The prompt appears again.

A deterministic app-server regression test could:

1. Initialize app-server with clientInfo.name = "codex-tui".
2. Start a parent thread and have it call spawn_agent.
3. Give the child a GitHub recommendation and make it invoke request_plugin_install.
4. Assert that no mcpServer/elicitation/request is emitted. Currently one is emitted because the child has no inherited client name.

What is the expected behavior?

Spawned and resumed child threads should inherit the parent client identity and UI capabilities before their first turn. A TUI child should not be offered or allowed to execute a plugin-install request that the TUI cannot fulfill. Multiple children should not create duplicate pending suggestions for the same plugin.

If installation is unsupported, the tool should return immediately without emitting an elicitation. If installation is supported, acceptance should only report success after installed-state verification succeeds.

Additional information

Root cause

The exact TUI guard exists, but spawned sessions lose the value it depends on:

1. SessionConfiguration initializes app_server_client_name and version to None.
2. spawn_agent_internal creates the child without inheriting the parent's app-server client context. It currently reads parent client metadata only for analytics after creating the child.
3. request_plugin_install rejects plugin installs only when the name exactly equals codex-tui. None therefore bypasses the guard.
4. The handler emits an MCP form and, after acceptance, only verifies whether installation happened elsewhere. The TUI itself performs no installation.
5. There is no tree-wide deduplication by plugin ID, so sibling and sequential children can repeat the request.

Suggested fix

• Before publishing a child thread or sending its initial input, inherit the parent's client name/version, supports_openai_form_elicitation, and MCP elicitation auto-deny setting. Apply this consistently to fresh, forked, nested, and resumed children.
• Fail closed when client support is missing or unknown, both while planning tool exposure and again in the handler before emitting an elicitation.
• Prefer an explicit negotiated supports_plugin_install_interstitial client capability over product-name string checks.
• Deduplicate pending and accepted-but-incomplete suggestions per root agent tree and canonical plugin ID.

Useful regression coverage:

• TUI parent -> child and nested child retain client context.
• A TUI child sees no GitHub install tool and emits no elicitation.
• A supported desktop child still receives the install UI.
• Concurrent sibling requests for the same plugin produce one suggestion.
• Accepting without installation remains incomplete and does not immediately re-prompt.

Upstream mitigation status

Codex 0.145.0 includes #32949, which requires an explicit plugin request, and #32894, which serializes installation requests. Those changes reduce prompt frequency but do not propagate child client identity, make TUI installation fulfillable, or deduplicate suggestions across the agent tree.

The closest existing report I found is #35387, which covers the related unfulfillable request_plugin_install path under codex exec, not the TUI/subagent identity-loss case.