[Feature]: opt into Codex client compaction without disabling V2 routing #3978

Area

Multiple areas

What are you trying to accomplish?

Keep OpenCodex V2 subagent routing, including provider-selected plaintext delivery or encrypted task passthrough, while letting Codex perform client-side context compaction. New compacted history should remain replayable after ocx restore or the dashboard Codex OFF action.

What prevents this today?

On an ordinary loopback install, OpenCodex uses Design B and injects only a root openai_base_url. Codex therefore keeps the built-in openai provider identity and selects native remote compaction for every routed model.

For noncanonical providers, OpenCodex converts the compaction turn into a summarizer request and stores the result as type: "compaction" with encrypted_content: "ocx1:<base64>". OpenCodex can decode that envelope while it remains in the path, but native ChatGPT cannot verify it after routing is disabled. This is the forward-looking cause behind the recovery case in #3916.

The V2 task-delivery capability and compaction ownership are independent, but the current loopback injection makes them behave as one choice.

Verified on dev commit 900567af3f (package 2.48.0):

• src/codex/inject.ts selects the root openai_base_url Design B form for authenticated loopback routing.
• The same file already supports a dedicated [model_providers.opencodex] form for non-loopback and authless Desktop routing.
• src/responses/compaction.ts documents and emits the OpenCodeX-owned ocx1: envelope for routed remote compaction V2.
• Codex client compaction uses a bare context_compaction marker followed by ordinary summary history, so it does not require OpenCodeX to decode a provider-private blob.

What should OpenCodex do?

Offer an explicit, default-off Codex client-compaction compatibility mode. When enabled on loopback routing, OpenCodex should use its dedicated opencodex model-provider table with requires_openai_auth = true, rather than overriding the built-in openai provider. This lets Codex select client compaction while retaining the normal ChatGPT sign-in gate and all existing OpenCodex request routing.

The setting should not change provider-level V2 agent-task policy. allowEncryptedV2AgentTasks, plaintext delivery, and recovery/fallback behavior must remain independent.

Observable requirements:

• Default/unset behavior stays byte-compatible with Design B.
• The opt-in generates a noncanonical model_provider = "opencodex" route with requires_openai_auth = true.
• Enabling or disabling it converges the managed Codex configuration through the existing sync path.
• Existing ocx1: history is not silently rewritten; Codex restore leaves ocx1-compacted threads unreplayable on the native backend #3916/fix(codex): recover ocx1-compacted threads for native replay #3920 remain the explicit recovery path.
• The dashboard and CLI explain that this favors native replay portability and may use third-party provider quota for summary generation.

Example usage or interface

ocx system settings --client-compaction on
ocx sync

Equivalent configuration:

{
  "codexClientCompaction": true
}

Expected managed Codex shape:

model_provider = "opencodex"

[model_providers.opencodex]
name = "OpenCodex Proxy"
base_url = "http://127.0.0.1:10100/v1"
wire_api = "responses"
requires_openai_auth = true

Provider configuration remains separate:

{
  "providers": {
    "example": {
      "adapter": "openai-responses",
      "baseUrl": "https://example.invalid/v1",
      "allowEncryptedV2AgentTasks": true
    }
  }
}

Alternatives or workarounds

• Keep Design B and use routed remote compaction. This preserves the built-in provider identity but continues creating OpenCodeX-owned ocx1: state for noncanonical providers.
• Enable codexDesktopAuthless. It already selects the provider-table form, but it also disables the Desktop ChatGPT login gate and is therefore not equivalent.
• Manually maintain a custom model_provider. OpenCodeX intentionally preserves external provider ownership and then does not manage normal routing or catalog convergence.
• Repair each affected thread after the fact. This is necessary for existing history but does not prevent new incompatible compaction state.

Additional context

• Related recovery issue: Codex restore leaves ocx1-compacted threads unreplayable on the native backend #3916
• Existing recovery PR: fix(codex): recover ocx1-compacted threads for native replay #3920
• Earlier remote-compaction compatibility issue: Remote compaction v2 fatals on API-key-based openai-responses providers — passthrough assumes native compaction support #422
• Compaction-provider routing issue: No way to set compaction provider. #2901

This proposal is intentionally limited to selecting the existing Codex provider-table injection form. It does not redesign the Responses relay, V2 task transport, compaction model routing, or history recovery.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.