Support plugin install entry metadata in TUI#28798
Conversation
zswang-oai
force-pushed
the
nm-codex/install-plugins-multiple-prompt
branch
from
70df46b to
bf33de5
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bf33de56ce
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| DiscoverableTool::Plugin(plugin) => { | ||
| if is_remote_plugin_install_suggestion(&plugin.id) { | ||
| false |
There was a problem hiding this comment.
When a remote plugin suggestion is accepted by an app-server client that doesn't include the new installed_entries content (older clients and the auto-accept path still resolve elicitations with empty content), this branch makes the only local verification path false; without an app-reported entry, the tool returns completed:false even though remote plugin installs were previously treated as completed because core cannot verify them locally. Keep the legacy success fallback when no picker acknowledgement is present, or this breaks existing app-server clients that accept the elicitation without the new response payload.
AGENTS.md reference: AGENTS.md:L103-L110
Useful? React with 👍 / 👎.
| RequestPluginInstallsMeta { | ||
| codex_approval_kind: REQUEST_PLUGIN_INSTALL_APPROVAL_KIND_VALUE, | ||
| persist: Some(REQUEST_PLUGIN_INSTALL_PERSIST_ALWAYS_VALUE), | ||
| suggest_type: args.action_type, | ||
| entries, | ||
| categories, |
There was a problem hiding this comment.
For single-entry install prompts sent through mcpServer/elicitation/request, this now emits only nested entries/categories metadata and drops the legacy top-level tool_type, tool_id, tool_name, suggest_reason, and install_url shape that app-server clients already parse to render tool suggestions; the TUI parser was updated in this commit, but other app-server clients receive _meta as opaque JsonValue and will no longer recognize these install prompts. Keep the legacy top-level fields for one-entry requests (or version the metadata) while adding the new picker shape.
AGENTS.md reference: AGENTS.md:L103-L110
Useful? React with 👍 / 👎.
| .get("entries") | ||
| .and_then(Value::as_array) | ||
| .and_then(|entries| entries.first()) | ||
| .and_then(Value::as_object) |
There was a problem hiding this comment.
When a picker request contains multiple flat entries or multiple categorized entries, this telemetry helper only extracts the first entry, so codex.plugin_install_elicitation_sent is emitted for just one suggested integration even though the handler records suggestion outcomes for every entry. Multi-install experiments will have skewed sent/conversion denominators for every entry after the first; iterate all picker entries or remove the per-tool dimensions for multi-entry elicitations.
Useful? React with 👍 / 👎.
zswang-oai
force-pushed
the
nm-codex/install-plugins-multiple-prompt
branch
from
bf33de5 to
08604af
Compare
zswang-oai
changed the title
zswang-oai
changed the title
zswang-oai
force-pushed
the
nm-codex/install-plugins-multiple-prompt
branch
from
bf2b1a7 to
08604af
Compare
zswang-oai
changed the title
2 participants
Why
The install picker needs per-entry metadata so desktop clients can render each candidate with its own Install button while preserving the existing Skip / Continue flow.
What changed
entriesandcategoriesmetadata in the TUI elicitation pathStack
This is PR 1 of 7.
Paired Codex Apps PR: https://github.com/openai/openai/pull/1019331