You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
openai Responses API error: {"detail":"The 'auto' model is not supported when using Codex with a ChatGPT account."} (tags: model=auto, provider=openai, operation=responses_api, status=400).
Root cause
The user's config carries the model string auto (a Codex-CLI alias). In chat_via_responses, openhuman builds the ResponsesRequest with model: model.to_string() (compatible_helpers.rs:70) and sends it unchanged to the ChatGPT-OAuth Codex /responses endpoint, which rejects auto (valid only for API-key Codex) with a 400. The is_codex_oauth_responses block already proactively adjusts two sibling Codex quirks — strips stream:false (#3201) and max_output_tokens (#4068 / TAURI-RUST-EWD) — but performs noauto→concrete-model remap, so the sentinel leaks to the provider. Emit site: compatible_helpers.rs:135.
Bucket / RCA
real-defect (model resolution). RCA fix: resolve/remap auto to a concrete model before the request so the provider never sees auto — within the is_codex_oauth_responses branch (mirroring the #3201 / EWD proactive-adjustment pattern at ~lines 40-78), substitute a concrete Codex-class model when model == "auto". Optionally normalize an autodefault_model at config/provider-factory load (cf. #4080's stale-default_model normalization).
Dedupe
NEW (distinct from the #4009 capability-gating 404 family — openai supports Responses; this is a 400 on the model field). Closest siblings #4068 / #4080 (same block/pattern) don't remap auto. No open PR / GH issue. Not covered by #4182-4189.
Source
Sentry: https://sentry.tinyhumans.ai/organizations/tinyhumans/issues/11825/ (TAURI-RUST-AHX)
Events: 1,246 · Users affected: 1 · First seen: 2026-06-06 · Last seen: 2026-06-26 (actively firing on 0.57.53)
Symptom
openai Responses API error: {"detail":"The 'auto' model is not supported when using Codex with a ChatGPT account."}(tags: model=auto, provider=openai, operation=responses_api, status=400).Root cause
The user's config carries the model string
auto(a Codex-CLI alias). Inchat_via_responses, openhuman builds theResponsesRequestwithmodel: model.to_string()(compatible_helpers.rs:70) and sends it unchanged to the ChatGPT-OAuth Codex/responsesendpoint, which rejectsauto(valid only for API-key Codex) with a 400. Theis_codex_oauth_responsesblock already proactively adjusts two sibling Codex quirks — stripsstream:false(#3201) andmax_output_tokens(#4068 / TAURI-RUST-EWD) — but performs noauto→concrete-model remap, so the sentinel leaks to the provider. Emit site:compatible_helpers.rs:135.Bucket / RCA
real-defect(model resolution). RCA fix: resolve/remapautoto a concrete model before the request so the provider never seesauto— within theis_codex_oauth_responsesbranch (mirroring the #3201 / EWD proactive-adjustment pattern at ~lines 40-78), substitute a concrete Codex-class model whenmodel == "auto". Optionally normalize anautodefault_modelat config/provider-factory load (cf. #4080's stale-default_model normalization).Dedupe
NEW (distinct from the #4009 capability-gating 404 family — openai supports Responses; this is a 400 on the model field). Closest siblings #4068 / #4080 (same block/pattern) don't remap
auto. No open PR / GH issue. Not covered by #4182-4189.Suggested scope
src/openhuman/inference/provider/compatible_helpers.rs— inchat_via_responsesis_codex_oauth_responsesblock, remapmodel=="auto"before buildingResponsesRequest(follow Codex OAuth Responses API requests fail unless store=false is sent #3201 / EWD pattern ~40-78).config/schema/cloud_providers.rs/ provider-factory normalization of anautodefault_model.autois rewritten for the Codex OAuth responses endpoint.No AI-attribution trailers in commits/PR. Do NOT run local cargo — push --no-verify and let PR CI test.