[codex] Enable standalone web search in code mode

[rka-oai]

What

• Consume plaintext output from standalone search while retaining optional encrypted_output parsing.
• Expose web.run to code mode and return search output to nested JavaScript calls.
• Cover direct and code-mode standalone search paths with integration tests.

Why

/v1/alpha/search now returns plaintext output, which code mode needs to consume standalone search results.

Test plan

• just test -p codex-api
• just test -p codex-web-search-extension
• just test -p codex-core code_mode_can_call_standalone_web_search
• just test -p codex-app-server standalone_web_search_round_trips_output

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e28d2a19b4

ℹ️ 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".

[chatgpt-codex-connector]

Preserve encrypted search output for model-visible replies

When web.run is called as a normal model-visible tool (the app-server test still exercises that path), this line discards the returned encrypted_output and later sends output as input_text in the next Responses request. That injects the full standalone search result into model history instead of the encrypted content, and the root AGENTS.md “Model visible context” rule requires new model-context fragments that can exceed 1k tokens to be highlighted and bounded. Keep the encrypted payload for to_response_item while using plaintext only for code-mode results.

Useful? React with 👍 / 👎.

[sayan-oai]

pseudo related to this, there is some token accounting for tool call output. previously this was encrypted so responses added a max_output_tokens field (because we couldn’t truncate encrypted content in the harness safely), but now that it’s not can/does this output go through the normal tool call accounting that tracks + truncates large results?

EDIT: nvm, we get this for free

[parasol-aser]

ext/web-search/src/output.rs — to_response_item (the // TODO: ... honor memories.disable_on_external_context you left). Standalone search emits its content as a FunctionCallOutput, but response_item_may_include_external_context in core/src/stream_events_utils.rs only matches ToolSearchCall/ToolSearchOutput/WebSearchCall, so the thread is never marked memory-polluted for this tool. With disable_on_external_context enabled, an operator who turned the guard on specifically to keep untrusted web text out of persisted memory doesn't actually get that protection here — and this PR makes the bypassed content plaintext the model reads and reachable from code mode, so it bites harder than before. The ExtensionTurnItem::WebSearch you also emit becomes a TurnItem::WebSearch, not a WebSearchCall, so it doesn't cover for it either.

Fix: add FunctionCallOutput (ideally a provenance-tagged variant so unrelated function outputs aren't over-matched) to the matcher, or mark pollution at this tool's output boundary, and add a test with disable_on_external_context enabled asserting the thread gets marked.

ext/web-search/src/output.rs:33-42 — to_response_item / code_mode_result. Switching the result from EncryptedContent to InputText plus the Direct exposure means upstream search text now lands verbatim in the model context and the code-mode sandbox value, where previously it was opaque ciphertext the local model never saw. It's returned as a value, not interpolated into code, and it mirrors the existing Direct image-generation tool, so this is a surface expansion rather than a new code-exec sink — but it's worth being deliberate about: nothing tags this text as untrusted/external between response.output and either sink.

Fix: consider attaching untrusted/external provenance (and a length cap) to the search output so downstream handling can treat it as data rather than instructions. Reasonable to accept as-is if that matches the intended trust model — flagging so it's a conscious call.

[sayan-oai]

codex:

Should this PR also make standalone search honor memories.disable_on_external_context? This output is recorded as a normal FunctionCallOutput, which the external-context detector does not recognize, so plaintext web results remain eligible for memory generation even when that setting is enabled.

[rka-oai]

adding a func on tool output to allow us to do this cleanly. It is bit out of the scope of this PR (since its creating something reusable for future external tool calls), so I've stacked a follow up PR to resolve this issue: #26821