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:
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
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
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 restoreor 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-inopenaiprovider 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"withencrypted_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
devcommit900567af3f(package 2.48.0):src/codex/inject.tsselects the rootopenai_base_urlDesign B form for authenticated loopback routing.[model_providers.opencodex]form for non-loopback and authless Desktop routing.src/responses/compaction.tsdocuments and emits the OpenCodeX-ownedocx1:envelope for routed remote compaction V2.context_compactionmarker 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
opencodexmodel-provider table withrequires_openai_auth = true, rather than overriding the built-inopenaiprovider. 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:
model_provider = "opencodex"route withrequires_openai_auth = true.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.Example usage or interface
Equivalent configuration:
{ "codexClientCompaction": true }Expected managed Codex shape:
Provider configuration remains separate:
{ "providers": { "example": { "adapter": "openai-responses", "baseUrl": "https://example.invalid/v1", "allowEncryptedV2AgentTasks": true } } }Alternatives or workarounds
ocx1:state for noncanonical providers.codexDesktopAuthless. It already selects the provider-table form, but it also disables the Desktop ChatGPT login gate and is therefore not equivalent.model_provider. OpenCodeX intentionally preserves external provider ownership and then does not manage normal routing or catalog convergence.Additional context
openai-responsesproviders — passthrough assumes native compaction support #422This 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