Issue Station
Sign In
Tools hereToolbox

codex - ✅(Solved) Fix Azure provider silently uses local compaction instead of `POST /responses/compact` [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#17773•Fetched 2026-04-15 06:28:36
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
ivanmurashkoivanmurashko
Participants
ivanmurashkoivanmurashko
Timeline (top)
labeled ×4unlabeled ×1

Error Message

When using an Azure OpenAI provider (name = "Azure" or an Azure base URL), Codex silently falls back to local model-generated compaction instead of calling POST /responses/compact, even though Azure's Responses API fully supports it. No error or warning is shown.

Root Cause

The compaction routing gate in core/src/compact.rs checks only is_openai():

pub(crate) fn should_use_remote_compact_task(provider: &ModelProviderInfo) -> bool {
    provider.is_openai()   // true only when name == "OpenAI" (exact, case-sensitive)
}

The standard Azure configuration requires name = "Azure" to activate attach_item_ids via is_azure_responses_endpoint() (case-insensitive check in codex-api/src/provider.rs). But that same name makes is_openai() return false, silently disabling remote compaction. The two checks are mutually exclusive — no single name value satisfies both.

nameis_openai()is_azure_responses_endpoint()Result
"OpenAI"✓✗Remote compaction on, attach_item_ids off (breaks Azure)
"Azure"✗✓Remote compaction off, attach_item_ids on

PR fix notes

PR #17958: Support remote compaction for Azure responses providers

Description (problem / solution / changelog)

Azure Responses providers were still falling back to local compaction because the compaction gate only checked ModelProviderInfo::is_openai().

Move the capability check onto ModelProviderInfo with supports_remote_compaction(), backed by the existing Azure Responses endpoint detection used in codex-api, and have core::compact delegate to that helper.

Add regression coverage for:

  • OpenAI providers using remote compaction
  • Azure providers using remote compaction
  • non-OpenAI/non-Azure providers staying on the local path

resolves #17773

Changed files

  • codex-rs/core/src/compact.rs (modified, +1/-1)
  • codex-rs/core/src/compact_tests.rs (modified, +26/-0)
  • codex-rs/model-provider-info/src/lib.rs (modified, +5/-0)
  • codex-rs/model-provider-info/src/model_provider_info_tests.rs (modified, +55/-0)

Code Example

pub(crate) fn should_use_remote_compact_task(provider: &ModelProviderInfo) -> bool {
    provider.is_openai()   // true only when name == "OpenAI" (exact, case-sensitive)
}
RAW_BUFFERClick to expand / collapse

Problem

When using an Azure OpenAI provider (name = "Azure" or an Azure base URL), Codex silently falls back to local model-generated compaction instead of calling POST /responses/compact, even though Azure's Responses API fully supports it. No error or warning is shown.

Root Cause

The compaction routing gate in core/src/compact.rs checks only is_openai():

pub(crate) fn should_use_remote_compact_task(provider: &ModelProviderInfo) -> bool {
    provider.is_openai()   // true only when name == "OpenAI" (exact, case-sensitive)
}

The standard Azure configuration requires name = "Azure" to activate attach_item_ids via is_azure_responses_endpoint() (case-insensitive check in codex-api/src/provider.rs). But that same name makes is_openai() return false, silently disabling remote compaction. The two checks are mutually exclusive — no single name value satisfies both.

nameis_openai()is_azure_responses_endpoint()Result
"OpenAI"✓✗Remote compaction on, attach_item_ids off (breaks Azure)
"Azure"✗✓Remote compaction off, attach_item_ids on

extent analysis

TL;DR

The issue can be resolved by modifying the should_use_remote_compact_task function to also check for Azure providers.

Guidance

  • Update the should_use_remote_compact_task function to check for both OpenAI and Azure providers using a case-insensitive comparison.
  • Verify that the is_azure_responses_endpoint function is correctly setting attach_item_ids to true for Azure configurations.
  • Test the updated function with both OpenAI and Azure configurations to ensure remote compaction is working as expected.
  • Consider adding a warning or error message when the compaction routing gate falls back to local model-generated compaction.

Example

pub(crate) fn should_use_remote_compact_task(provider: &ModelProviderInfo) -> bool {
    provider.is_openai() || provider.name.to_lowercase() == "azure"
}

Notes

This solution assumes that the is_openai and is_azure_responses_endpoint functions are correctly implemented and that the issue is solely due to the mutually exclusive checks.

Recommendation

Apply workaround: update the should_use_remote_compact_task function to check for both OpenAI and Azure providers. This will allow remote compaction to work correctly for Azure configurations while still supporting OpenAI providers.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#SSR setup#ISR setup#authentication setup#request error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING