[app-server] Add client-only web search result metadata#31515
[app-server] Add client-only web search result metadata#31515alexi-openai wants to merge 1 commit into
Conversation
![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: 3c6ad5ea3d
ℹ️ 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".
| id: String, | ||
| query: String, | ||
| action: Option<WebSearchAction>, | ||
| results: Option<Vec<WebSearchResult>>, |
There was a problem hiding this comment.
This adds results to the app-server v2 webSearch ThreadItem that is returned by thread/read and item/* notifications, but the README's Items section still documents webSearch as {id, query, action?} (I checked codex-rs/app-server/README.md). Clients relying on the documented app-server API will miss the new metadata unless the README/example is updated with the schema change.
AGENTS.md reference: AGENTS.md:L298-L300
Useful? React with 👍 / 👎.
| skip_serializing_if = "Option::is_none" | ||
| )] | ||
| #[ts(optional)] | ||
| pub results: Option<Vec<WebSearchResult>>, |
There was a problem hiding this comment.
When an extension emits a WebSearchItem with non-empty results, these public fields are persisted and sent to clients as-is; the new bounding function only runs during deserialization of already-serialized events. That means an extension can still emit a huge URL/title/snippet payload and bypass the intended caps for live notifications and rollout writes, so the results should be normalized at the emission/construction boundary before serialization.
Useful? React with 👍 / 👎.
1 participant
Summary
Provider follow-ups are split into #31379 for hosted Responses and #31516 for standalone /alpha/search.
Model-context boundary
This PR does not change ResponseItem, WebSearchAction, or Responses request construction. The metadata exists only on client-facing WebSearchItem/WebSearchEndEvent values, so it is not added to what the model sees.
Validation