Web search fails for ChatGPT Plus because ChatGPT search provider hardcodes `gpt-5.3-codex`

[bendelaney]

Craft Agents Version

0.11.1

Operating System

macOS (Apple Silicon)

OS Version

macOS 25.5.0

AI Provider

OpenAI / Codex

Model

pi/gpt-5.6-sol

Description

When using a ChatGPT Plus / openai-codex connection, web search can fail before it even gets to the actual query because the ChatGPT search provider hardcodes gpt-5.3-codex as the search model.

On my setup, the active session model is pi/gpt-5.6-sol and the ChatGPT Plus connection default is pi/gpt-5.6-terra, but the search path ignores both and sends gpt-5.3-codex to the ChatGPT backend.

That produces this error:

Search failed for "site:developer.getjobber.com Jobber GraphQL visit edit scheduled item mutation": primary (ChatGPT) failed with "ChatGPT search failed: web_search failed (HTTP 400) [tool=web_search, model=gpt-5.3-codex, store=false, stream=true, tool_choice=auto, text.verbosity=medium, content-type=application/json]: {\"detail\":\"The 'gpt-5.3-codex' model is not supported when using Codex with a ChatGPT account.\"}; web_search_preview failed (HTTP 400) [tool=web_search_preview, model=gpt-5.3-codex, store=false, stream=true, tool_choice=auto, text.verbosity=medium, content-type=application/json]: {\"detail\":\"The 'gpt-5.3-codex' model is not supported when using Codex with a ChatGPT account.\"}"; fallback (DuckDuckGo) failed with "All DuckDuckGo endpoints failed: ddg_primary:DDG detected an anomaly in the request, you are likely making requests too quickly.; ddg_html:No results parsed from DDG HTML; ddg_lite:No results parsed from DDG Lite HTML"

I traced the immediate cause to:

• packages/pi-agent-server/src/tools/search/providers/chatgpt.ts
  • const DEFAULT_SEARCH_MODEL = 'gpt-5.3-codex';
• packages/pi-agent-server/src/tools/search/SEARCH_PAYLOAD_CONTRACT.md
  • documents model: "gpt-5.3-codex" as the known-good payload

And the provider resolution path appears to be:

• resolveSearchProvider() sees provider === 'openai-codex'
• it instantiates ChatGPTBackendSearchProvider
• that provider hardcodes gpt-5.3-codex unless overridden

So this looks like a stale hardcoded search-model assumption rather than a workspace/source configuration issue.

Steps to Reproduce

1. Configure Craft Agents with a ChatGPT Plus / openai-codex connection.
2. Use a session backed by that connection (in my case, chatgpt-plus).
3. Trigger a web search from the agent.
4. Inspect the error when search fails.
5. Note that the request fingerprint reports model=gpt-5.3-codex even if the active session model is something newer.

Expected Behavior

Web search should use a model that is supported for the current ChatGPT/Codex account, or derive the search model from the active connection/runtime instead of hardcoding a stale one.

If the primary model is unsupported, the search path should fail over to another compatible provider-native model before immediately cascading to DuckDuckGo.

Actual Behavior

The ChatGPT search provider sends gpt-5.3-codex, receives HTTP 400 with:

The 'gpt-5.3-codex' model is not supported when using Codex with a ChatGPT account.

It then retries web_search_preview with the same unsupported model, fails again, and finally falls back to DuckDuckGo, which can also fail/rate-limit.

Screenshots / Screen Recordings

None.

Debug Logs

Search failed for "site:developer.getjobber.com Jobber GraphQL visit edit scheduled item mutation": primary (ChatGPT) failed with "ChatGPT search failed: web_search failed (HTTP 400) [tool=web_search, model=gpt-5.3-codex, store=false, stream=true, tool_choice=auto, text.verbosity=medium, content-type=application/json]: {"detail":"The 'gpt-5.3-codex' model is not supported when using Codex with a ChatGPT account."}; web_search_preview failed (HTTP 400) [tool=web_search_preview, model=gpt-5.3-codex, store=false, stream=true, tool_choice=auto, text.verbosity=medium, content-type=application/json]: {"detail":"The 'gpt-5.3-codex' model is not supported when using Codex with a ChatGPT account."}"; fallback (DuckDuckGo) failed with "All DuckDuckGo endpoints failed: ddg_primary:DDG detected an anomaly in the request, you are likely making requests too quickly.; ddg_html:No results parsed from DDG HTML; ddg_lite:No results parsed from DDG Lite HTML"

Additional Context

A few details from my local investigation:

• ~/.craft-agent/config.json has defaultLlmConnection: "chatgpt-plus"
• that connection's defaultModel is pi/gpt-5.6-terra
• the current session model was pi/gpt-5.6-sol
• there was no workspace-level or source-level override setting gpt-5.3-codex
• the failing model appears to come only from the search-provider implementation itself

A minimal fix would be to stop hardcoding gpt-5.3-codex in the ChatGPT backend search provider. More robustly, the provider could derive its search model from current connection/runtime capabilities, or at least retry with a supported model when the backend returns an unsupported-model 400.