Client or integration
Codex App
Affected providers
Multiple third-party / OpenAI-compatible providers.
I first observed this with Console Go, but this is not specific to OpenCode Go.
Current behavior
When using recent Codex App versions through OpenCodex with third-party providers, some requests fail immediately because the upstream receives the Codex Responses API field access_programs.
Example error:
Error from provider (Console Go): Upstream request failed: [invalid_request_error] unknown parameter `access_programs`
I have observed the same class of failure with more than one provider, so this appears to be a generic Responses/provider compatibility issue rather than an OpenCode Go-specific problem.
Recent Codex versions include the optional field:
#[serde(skip_serializing_if = "Option::is_none")]
pub access_programs: Option<AccessPrograms>,
in ResponsesApiRequest.
The normal Codex request construction path currently initializes it as:
but Codex also has paths where access_programs may be populated and serialized onto the wire.
When such a request is routed through OpenCodex to a provider that does not implement this OpenAI/Codex-specific field, the upstream rejects the entire request.
Expected behavior
OpenCodex should normalize Responses API payloads according to the capabilities of the selected upstream provider.
For providers that do not support access_programs, the field should be stripped before forwarding.
If a provider supports an equivalent capability with a different representation, OpenCodex should translate it instead.
A Codex-specific optional request field should not make otherwise compatible third-party providers unusable.
Minimal reproduction
- Configure a third-party / OpenAI-compatible provider in OpenCodex.
- Use it from recent Codex App.
- Start a normal inference request.
- Observe the forwarded request being rejected by the upstream with an unknown-parameter error for
access_programs.
Example:
[invalid_request_error] unknown parameter `access_programs`
Scope
This does not appear to be specific to OpenCode Go.
I have reproduced the same class of failure across multiple providers that otherwise accept Codex/OpenAI-compatible requests but do not recognize access_programs.
This suggests the compatibility boundary may belong in the generic Responses forwarding / provider normalization layer rather than in one provider-specific adapter.
Possible root cause
Not confirmed yet.
Two possibilities seem worth checking:
- Codex App is legitimately populating
access_programs for some requests/models, and OpenCodex forwards it unchanged to providers that do not support it.
- OpenCodex reconstructs or preserves the field during Responses transformation without checking upstream capability.
Either way, the important invariant seems to be:
Provider-specific upstream requests should only contain fields supported by that provider.
Suggested direction
Before forwarding a Responses request to a third-party provider:
- determine whether the provider supports
access_programs;
- strip it when unsupported;
- or map it only for providers with an equivalent capability.
Ideally this should be handled in the common Responses compatibility layer rather than patched independently in each provider.
Notes
Codex currently defines access_programs directly in its Responses API request schema and skips serialization only when the value is None.
There are also explicit code/test paths where access_programs is populated and included in the wire payload, so treating it as a field that may legitimately arrive from newer Codex clients seems safer than assuming it will always be absent.
Checks
Client or integration
Codex App
Affected providers
Multiple third-party / OpenAI-compatible providers.
I first observed this with Console Go, but this is not specific to OpenCode Go.
Current behavior
When using recent Codex App versions through OpenCodex with third-party providers, some requests fail immediately because the upstream receives the Codex Responses API field
access_programs.Example error:
I have observed the same class of failure with more than one provider, so this appears to be a generic Responses/provider compatibility issue rather than an OpenCode Go-specific problem.
Recent Codex versions include the optional field:
in
ResponsesApiRequest.The normal Codex request construction path currently initializes it as:
but Codex also has paths where
access_programsmay be populated and serialized onto the wire.When such a request is routed through OpenCodex to a provider that does not implement this OpenAI/Codex-specific field, the upstream rejects the entire request.
Expected behavior
OpenCodex should normalize Responses API payloads according to the capabilities of the selected upstream provider.
For providers that do not support
access_programs, the field should be stripped before forwarding.If a provider supports an equivalent capability with a different representation, OpenCodex should translate it instead.
A Codex-specific optional request field should not make otherwise compatible third-party providers unusable.
Minimal reproduction
access_programs.Example:
Scope
This does not appear to be specific to OpenCode Go.
I have reproduced the same class of failure across multiple providers that otherwise accept Codex/OpenAI-compatible requests but do not recognize
access_programs.This suggests the compatibility boundary may belong in the generic Responses forwarding / provider normalization layer rather than in one provider-specific adapter.
Possible root cause
Not confirmed yet.
Two possibilities seem worth checking:
access_programsfor some requests/models, and OpenCodex forwards it unchanged to providers that do not support it.Either way, the important invariant seems to be:
Suggested direction
Before forwarding a Responses request to a third-party provider:
access_programs;Ideally this should be handled in the common Responses compatibility layer rather than patched independently in each provider.
Notes
Codex currently defines
access_programsdirectly in its Responses API request schema and skips serialization only when the value isNone.There are also explicit code/test paths where
access_programsis populated and included in the wire payload, so treating it as a field that may legitimately arrive from newer Codex clients seems safer than assuming it will always be absent.Checks
access_programs