Azure /responses/compact 5xx should fall back to local auto compaction

Summary

Azure Responses remote compaction can return transient 5xx / high-demand errors for long-running Codex sessions. When this happens, Codex currently exhausts the remote retry budget and aborts the turn instead of falling back to local compaction.

I think Codex should degrade gracefully:

remote auto compaction succeeds -> keep current behavior
remote auto compaction fails with transient 5xx/high-demand/stream/transport error -> fall back to local auto compaction
auth/usage/cancel/context-window/4xx errors -> keep current error behavior

Environment

• Codex CLI: 0.135.0
• Provider: Azure Responses
• Region observed: East US 2
• Models observed:
  • gpt-5.4-mini
  • gpt-5.4
  • gpt-5.5
• model_context_window: 258400
• model_auto_compact_token_limit: tested with 80000 and 100000

No API keys, bearer tokens, or secrets are included in this report.

Observed behavior

For long-running / large-context sessions, Codex attempts remote compaction:

endpoint="/responses/compact"

The Azure backend returns:

http.response.status_code=500
error.message="http 500"
compact_error="We're currently experiencing high demand, which may cause temporary errors."

Example request IDs:

x-request-id: 3dbc52a9-f643-44eb-84e3-796e18daa354
apim-request-id: d1533a38-3ccb-4b04-85c9-7e5d87876d15

x-request-id: ec518e5c-b095-4db1-b08a-49b2893af1f7
apim-request-id: d1329d8d-c723-475b-aa36-1246e86eb4a3

The turn fails after remote retry attempts.

Expected behavior

If remote auto compaction fails with a transient backend/transport error, Codex should fall back to local auto compaction and continue the turn.

It should not fall back for non-transient failures such as:

• auth failures
• usage/quota failures
• cancellation/interruption
• context window exceeded
• 4xx invalid request errors

Related context

This is related to Azure remote compaction support added after:

• Azure provider silently uses local compaction instead of POST /responses/compact #17773
• Support remote compaction for Azure responses providers #17958

That issue fixed Azure providers not using remote compaction. This issue is about the next failure mode: Azure remote compaction is used, but transient /responses/compact failures abort the turn instead of falling back.

Azure's Responses API docs also describe server-side compaction via context_management, but Codex currently calls the separate /responses/compact endpoint.

Proposed fix

I have a candidate patch here:

https://github.com/hueifeng/codex/tree/fix/remote-compaction-local-fallback

The patch:

• adds a compaction-specific transient fallback predicate
• falls back from remote auto compaction to local auto compaction for transient errors
• preserves current behavior for auth/usage/cancel/context-window/4xx errors
• includes unit tests for fallback classification
• includes an integration test where /responses/compact returns repeated 500 responses and the turn continues via local compaction

Commits:

8e760da Fall back to local compaction on transient remote failures
9c481fd Cover remote compaction fallback integration

Tests run

just fmt
just test -p codex-core remote_pre_turn_compaction_5xx_falls_back_to_local_compaction falls_back_to_local_compact does_not_fallback_to_local_compact

Result:

3 tests run: 3 passed

Why this matters

For long-running Codex sessions, a transient Azure /responses/compact failure currently makes the whole session unusable. Falling back to local compaction gives Codex a safe degradation path without provider-name hacks or user config changes.