Model ID normalization breaks OCI OpenAI-compatible models with provider prefixes

What version of the Codex App are you using (From “About Codex” dialog)?

v0.142.0

What subscription do you have?

custom model

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Problem Description

Since the 2026-06-22(v0.142.0 ) Codex update, the model name resolution logic incorrectly normalizes OCI OpenAI-compatible model IDs that use provider prefixes.

OCI requires the full model ID with provider prefix (e.g., openai.gpt-5.5), but Codex's model resolution may treat it as a standard model slug and send only the base name (e.g., gpt-5.5) to the upstream API, causing request failures.

Root Cause

The issue is in the find_model_by_longest_prefix function in codex-rs/models-manager/src/manager.rs manager.rs:456-472 . It uses starts_with to match model slugs, which causes false positives:

fn find_model_by_longest_prefix(model: &str, candidates: &[ModelInfo]) -> Option<ModelInfo> {  
    let mut best: Option<ModelInfo> = None;  
    for candidate in candidates {  
        if !model.starts_with(&candidate.slug) {  
            continue;  
        }  
        // ...  
    }  
    best  
}

When requesting openai.gpt-5.5, this function incorrectly matches it to gpt-5.5 because openai.gpt-5.5 starts_with("gpt-5.5") returns true.

The system already has special handling for slash-separated namespaces (e.g., custom/gpt-5.2-codex) in find_model_by_namespaced_suffix manager.rs:474-491 , but lacks equivalent logic for dot-separated provider prefixes.

What steps can reproduce the bug?

OCI requires the full model ID with provider prefix (e.g., openai.gpt-5.5), but Codex's model resolution may treat it as a standard model slug and send only the base name (e.g., gpt-5.5) to the upstream API, causing request failures.

What is the expected behavior?

Expected Behavior

When a user requests openai.gpt-5.5, Codex should:

• Recognize this as a provider-prefixed model ID
• Match it exactly to a catalog entry with slug openai.gpt-5.5
• Send openai.gpt-5.5 to the upstream API

Actual Behavior

When requesting openai.gpt-5.5:

• The longest-prefix match may incorrectly match it to gpt-5.5 from bundled models
• The system sends gpt-5.5 to the upstream API instead of openai.gpt-5.5
• OCI rejects the request due to invalid model ID

Additional information

Suggested Fix

Extend the model resolution logic to handle dot-separated provider prefixes similarly to how slash-separated namespaces are handled. Options include:

• Add a find_model_by_dot_prefixed function that treats openai. as a provider prefix
• Modify find_model_by_longest_prefix to require word boundaries or exact matches for standard slugs
• Add provider-specific model catalog handling that preserves full model IDs