[Responses compatibility] Third-party providers reject requests containing unsupported access_programs parameter #4907

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:

access_programs: None,

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

1. Configure a third-party / OpenAI-compatible provider in OpenCodex.
2. Use it from recent Codex App.
3. Start a normal inference request.
4. 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:

1. Codex App is legitimately populating access_programs for some requests/models, and OpenCodex forwards it unchanged to providers that do not support it.
2. 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

• Searched existing issues for access_programs
• Confirmed this is not limited to OpenCode Go
• Removed API keys, account identifiers, and credentials
• Exact provider list can be added if useful