Client or integration
OpenCodex Dashboard / Codex App
Area
Dashboard · Proxy and routing · Web-search sidecar
Summary
On OpenCodex 2.31.0, selecting Gemini 3.7 Flash as the web-search sidecar in the Dashboard does not persist when the current sidecar backend is OpenAI (or unset). The save request is rejected with HTTP 400, and after the UI refreshes the picker returns to the default gpt-5.6-luna.
Writing the same pair directly to ~/.opencodex/config.json works, and the runtime successfully uses the Gemini sidecar:
"webSearchSidecar": {
"backend": "gemini",
"model": "gemini-3.7-flash"
}
This appears to be limited to the Dashboard management write validation, not the Gemini executor.
Version
2.31.0 (current npm latest)
Operating system
macOS 26.6.2 (Build 25G83)
Reproduction
- Start with
webSearchSidecar unset or configured as:
{
"backend": "openai",
"model": "gpt-5.6-luna"
}
- Open the OpenCodex Dashboard.
- In the web-search sidecar picker, select Gemini /
gemini-3.7-flash.
- Save the setting.
- Observe that the request is rejected with HTTP 400 and the picker returns to
gpt-5.6-luna.
Expected behavior
The Dashboard should persist the offered backend/model pair:
{
"backend": "gemini",
"model": "gemini-3.7-flash"
}
The same should work for every backend included in the web-search backend union.
Actual behavior
The backend is effectively validated as openai, so gemini-3.7-flash is rejected as an invalid OpenAI web-search model. The configuration is not written and the UI reloads the previous/default Luna selection.
Suspected root cause
Both management write routes still special-case only openai and anthropic when resolving the effective backend.
In src/server/management/config-routes.ts, the body.webSearch.backend resolver behaves approximately as follows:
const effectiveBackend = body.webSearch.backend === "anthropic"
? "anthropic"
: body.webSearch.backend === "openai" || body.webSearch.backend === null
? "openai"
: config.webSearchSidecar?.backend ?? "openai";
Therefore, a submitted backend: "gemini" is ignored during pair validation and falls back to the currently stored backend, commonly openai.
The equivalent resolver in src/server/management/agent-settings-routes.ts has the same openai/anthropic-only branching.
A possible fix is to preserve any submitted value accepted by WEB_SEARCH_BACKENDS_UNION / allowedBackends before validating the backend/model pair, and to add regression tests for switching from OpenAI/Luna to Gemini/Gemini 3.7 Flash through both PUT routes.
Workaround
Directly edit ~/.opencodex/config.json and set the Gemini pair. No source modification is required. Avoid changing the web-search picker again until the management write route is fixed.
Related work
Checks
Client or integration
OpenCodex Dashboard / Codex App
Area
Dashboard · Proxy and routing · Web-search sidecar
Summary
On OpenCodex 2.31.0, selecting Gemini 3.7 Flash as the web-search sidecar in the Dashboard does not persist when the current sidecar backend is OpenAI (or unset). The save request is rejected with HTTP 400, and after the UI refreshes the picker returns to the default
gpt-5.6-luna.Writing the same pair directly to
~/.opencodex/config.jsonworks, and the runtime successfully uses the Gemini sidecar:This appears to be limited to the Dashboard management write validation, not the Gemini executor.
Version
2.31.0(current npm latest)Operating system
macOS 26.6.2 (Build 25G83)
Reproduction
webSearchSidecarunset or configured as:{ "backend": "openai", "model": "gpt-5.6-luna" }gemini-3.7-flash.gpt-5.6-luna.Expected behavior
The Dashboard should persist the offered backend/model pair:
{ "backend": "gemini", "model": "gemini-3.7-flash" }The same should work for every backend included in the web-search backend union.
Actual behavior
The backend is effectively validated as
openai, sogemini-3.7-flashis rejected as an invalid OpenAI web-search model. The configuration is not written and the UI reloads the previous/default Luna selection.Suspected root cause
Both management write routes still special-case only
openaiandanthropicwhen resolving the effective backend.In
src/server/management/config-routes.ts, thebody.webSearch.backendresolver behaves approximately as follows:Therefore, a submitted
backend: "gemini"is ignored during pair validation and falls back to the currently stored backend, commonlyopenai.The equivalent resolver in
src/server/management/agent-settings-routes.tshas the same openai/anthropic-only branching.A possible fix is to preserve any submitted value accepted by
WEB_SEARCH_BACKENDS_UNION/allowedBackendsbefore validating the backend/model pair, and to add regression tests for switching from OpenAI/Luna to Gemini/Gemini 3.7 Flash through both PUT routes.Workaround
Directly edit
~/.opencodex/config.jsonand set the Gemini pair. No source modification is required. Avoid changing the web-search picker again until the management write route is fixed.Related work
Checks