Summary

Describe the problem and fix in 2–5 bullets:

• Problem: openai/gpt-5.3-codex was force-normalized to openai-codex/gpt-5.3-codex, which pushes API-key users into Codex OAuth flow and can fail with token/account extraction errors.
• Why it matters: users explicitly selecting openai provider should not be silently rerouted to a different provider/auth path.
• What changed: removed hard remap from model normalization; openai/gpt-5.3-codex now stays on openai.
• What changed (forward-compat): added openai provider support for gpt-5.3-codex forward-compat model fallback (using openai-responses / https://api.openai.com/v1), while preserving existing openai-codex/github-copilot behavior.
• What did NOT change (scope boundary): no change to openai-codex/* explicit refs, no auth-profile format changes, no provider usage accounting schema changes.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: gpt-5.3-codex is hard-routed to openai-codex OAuth provider in 2026.2.26, blocking API-key usage on openai provider #30844

User-visible / Behavior Changes

• openai/gpt-5.3-codex now remains on provider openai instead of being rerouted to openai-codex.
• Forward-compat fallback can now resolve openai provider gpt-5.3-codex via template cloning.

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node.js + pnpm workspace
• Model/provider: openai / openai-codex
• Integration/channel (if any): model selection + embedded runner model resolution
• Relevant config (redacted): agents.defaults.model.primary: openai/gpt-5.3-codex

Steps

1. Set primary model to openai/gpt-5.3-codex.
2. Resolve model reference and fallback candidate path.
3. Verify provider remains openai and forward-compat fallback resolves model metadata.

Expected

• No forced provider swap to openai-codex when user explicitly uses openai.
• openai fallback model for gpt-5.3-codex remains resolvable.

Actual

• Updated behavior and tests confirm openai is preserved and fallback resolution succeeds.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Commands run:

• pnpm exec oxfmt --check CHANGELOG.md src/agents/model-selection.ts src/agents/model-selection.test.ts src/agents/model-fallback.test.ts src/agents/model-forward-compat.ts src/agents/pi-embedded-runner/model.test-harness.ts src/agents/pi-embedded-runner/model.forward-compat.test.ts src/agents/pi-embedded-runner/model.test.ts
• pnpm exec vitest run src/agents/model-selection.test.ts src/agents/model-fallback.test.ts src/agents/pi-embedded-runner/model.forward-compat.test.ts src/agents/pi-embedded-runner/model.test.ts
• pnpm exec vitest run src/gateway/session-utils.test.ts src/commands/agent.acp.test.ts src/commands/sessions.model-resolution.test.ts
• pnpm exec vitest run src/agents/model-auth.profiles.test.ts src/commands/models/list.list-command.forward-compat.test.ts
• pnpm build

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified model parsing/normalization now preserves openai for gpt-5.3-codex refs.
• Verified fallback runner uses openai candidate (not forced openai-codex) for gpt-5.3-codex.
• Verified embedded runner forward-compat resolution works for both openai and openai-codex providers.
• What you did not verify: live end-to-end API calls against production OpenAI and Codex OAuth accounts in this cycle.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: revert this PR commit.
• Files/config to restore: src/agents/model-selection.ts and src/agents/model-forward-compat.ts.
• Known bad symptoms reviewers should watch for: explicit openai/gpt-5.3-codex unexpectedly routing back to openai-codex or unresolved unknown-model errors for openai/gpt-5.3-codex.

Risks and Mitigations

• Risk:
  • Deployments relying on implicit historical remap from openai to openai-codex for gpt-5.3-codex could observe provider behavior change.
  • Mitigation:
    • Explicit openai-codex/* refs are unchanged; forward-compat fallback now supports openai provider path with dedicated tests.

AI-assisted: Yes (Codex). Testing degree: fully tested for this change scope.