Support multi-tool install requests#27640
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6970178665
ℹ️ 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".
|
All contributors have signed the CLA ✍️ ✅ |
9346e5a to
bf9bdbd
Compare
|
I have read the CLA Document and I hereby sign the CLA |
fb6dbdd to
5b5e13c
Compare
5b5e13c to
869eaa3
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 869eaa3a58
ℹ️ 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".
| parameters: JsonSchema::one_of( | ||
| vec![flat_picker_schema(), categorized_picker_schema()], |
There was a problem hiding this comment.
Keep function parameters rooted at an object
When this tool is exposed, the Responses API receives a function parameters schema whose root is oneOf, but OpenAI's supported schema subset requires the root schema to be an object, not a root union (docs). This can make turns with tool-suggest enabled fail request validation before the model runs; keep the root as an object and let the handler enforce exactly one of entries or categories.
Useful? React with 👍 / 👎.
| planned_tools.add(RequestPluginInstallHandler::new( | ||
| discoverable_tools.to_vec(), | ||
| )); |
There was a problem hiding this comment.
Hide the legacy install tool from the model
When tool suggestions are enabled, this registers the legacy request_plugin_install handler with the default direct exposure, so it is still sent in the model-visible tool list alongside request_plugin_installs. That leaves the model free to keep choosing the single-target contract even though the list-tool guidance now points to the new multi-install picker; register this handler dispatch-only so resumed calls still work without advertising the obsolete shape.
Useful? React with 👍 / 👎.
| } | ||
| } | ||
|
|
||
| fn supports_parallel_tool_calls(&self) -> bool { |
There was a problem hiding this comment.
Serialize install requests with other tools
When the model emits request_plugin_installs together with another parallel-capable call, this opt-in lets the runtime run them concurrently even though the tool description says not to call it in parallel and the handler waits on a user-facing picker. That can let other work proceed before the install decision/verification completes; leave this at the default non-parallel behavior for the new elicitation tool.
Useful? React with 👍 / 👎.
4afa5bf to
e60b2a3
Compare
e60b2a3 to
2336949
Compare
0c7a6a4 to
8c9169f
Compare
11f472d to
259cc7a
Compare
|
Two small follow-ups from the endpoint work:
|
eed5cec to
70df46b
Compare
70df46b
into
nm-codex/plugin-installs-extension
09faee0 to
01b4cab
Compare
Why
Codex needs a single model-facing install request that can present either one recommendation or a grouped set of plugin/connector choices.
This is PR 1 of 4 in the review stack and remains the behavioral foundation. The extension refactor starts in #28796.
Paired Codex Apps PR: https://github.com/openai/openai/pull/1019331
What changed
request_plugin_installflow withrequest_plugin_installs(tool_type, tool_id)validation against known discoverable tools