[Provider compatibility]: Kimi Coding Responses rejects output.encrypted_content from Codex App #8075

Client or integration

Codex App (macOS).

Provider or upstream service

Kimi Coding Plan, API-key authentication, provider kimi-code, K3.1 Pro Standard context. Requested selector: kimi-code/k3.1-pro[256k]; observed effort: high; adapter: openai-responses.

OpenCodex version

Observed live on installed OpenCodex 2.94.0 with unrelated local compatibility changes. The Kimi include-filter change proposed below has not been installed. This is not claimed to be a pristine-stock reproduction.

I also inspected the tagged v2.96.0 source: the existing stripUnsupportedOutputInclude call remains gated to xAI, Meta and Azure destinations, not Kimi. No live request was made against v2.96.0.

Bundled Codex CLI/runtime reports 0.166.0-alpha.5.1; this is not an independently verified Codex Desktop application build number.

Endpoint or capability

Codex App Responses → OpenCodex → https://api.kimi.com/coding/v1/responses. Request include compatibility, without switching to Chat Completions.

Current behaviour

Continuing an existing Codex App chat on Kimi fails before any requested local read-only tool can execute or the assistant can produce a final answer.

The latest single logical continuation produced two observed proxy requests, each with one upstream send. Both used K3.1 Pro through openai-responses and returned HTTP 400 / invalid_request_error, classified as headers-only / payload-rejected. Usage was unreported, not proven to be zero.

The error identifies the unsupported output.encrypted_content include value. No raw request body, headers, authentication material, conversation content, or local session files were captured for this report.

Expected behaviour

Normalize this known-incompatible include entry at the Kimi Coding Responses boundary, while retaining the original Responses protocol, model, existing chat and its history.

Remove only the exact output.encrypted_content string from include. Preserve reasoning.encrypted_content, other include values, caller-owned input (including any compaction items), tool calls/results and all unrelated destination behavior. If removal leaves an empty include list, omit the field.

This should not require recreating a chat, rewriting/flattening history, switching wire protocols, or changing authentication.

Minimal redacted request or reproduction

Configuration shape (no credentials):

{
  "adapter": "openai-responses",
  "baseUrl": "https://api.kimi.com/coding/v1",
  "authMode": "key",
  "modelSuffixBracketStrip": true,
  "modelAdapters": {
    "k3.1-pro[256k]": "openai-responses"
  }
}

1. Configure a valid existing Kimi Coding Plan key; select kimi-code/k3.1-pro[256k] in Codex App with the Responses route.
2. On a client request containing the include entry below, ask for a harmless local read-only operation.
3. Observe the 400 before tool execution/final completion.

Synthetic request-shape illustration, not a captured full wire payload or a separately executed API reproduction:

{
  "model": "kimi-code/k3.1-pro[256k]",
  "input": [
    {"role": "user", "content": "Read the first line of an existing nonsensitive local test file, then reply briefly."}
  ],
  "include": ["reasoning.encrypted_content", "output.encrypted_content"],
  "stream": true
}

The example shows the request entering the proxy; normal route resolution and bracket-suffix stripping still apply. Tool declarations are omitted from this minimal illustration.

Actual response or error

HTTP 400 / invalid_request_error:

invalid_request_error: invalid_request_error: include value "output.encrypted_content" is not supported

Upstream documentation

• Kimi's official Codex integration (Coding Plan native Responses endpoint): https://www.kimi.com/code/docs/third-party-tools/codex.html
• Current Codex request-builder source conditionally adds this include entry: https://github.com/openai/codex/blob/main/codex-rs/core/src/client.rs#L1119-L1123
• Existing OpenCodex destination-scoped normalization in tagged v2.96.0: https://github.com/lidge-jun/opencodex/blob/v2.96.0/src/adapters/openai-responses/passthrough.ts#L361-L369

The concrete evidence that Kimi rejects this entry is the observed 400 above. The Codex source link is current source inspection, not proof of the original Desktop chat's loaded feature settings.

Suggested mapping or implementation notes

Please consider extending the existing exact-entry normalization to positively identified Kimi Coding Responses destinations, including the API-key provider above, without applying a global allowlist to arbitrary Responses gateways.

Useful offline regression cases:

• Kimi Coding Responses request loses only the rejected include entry.
• Supported/unknown other include entries and caller-owned input/tool/compaction items remain unchanged.
• Empty include is omitted.
• Unrelated or lookalike destinations are unchanged.
• No protocol switch, history conversion or retry is needed to work around the validation error.

If there is already a supported native configuration-only control that achieves this on an existing Codex App chat, please identify the exact setting and supported application method. A fresh CLI features list reports output_token_replay=false, but that does not establish the effective state of the loaded Desktop chat; no safe per-chat hot override has been verified.

Additional context and attachments

Related provider-specific cases: #7878 / #7911 (xAI), #7952 (Azure), #8037 (Zed). A targeted search found no existing Kimi report for this include error.

No attachments. No keys, account identifiers, request identifiers, conversation/session identifiers, local paths, private messages, business documents, or raw logs are included. Reporting this issue did not require any new model execution, payment, configuration changes, application restart or installation.

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted; the synthetic illustration is explicitly distinguished from captured/live evidence.
• The expected behaviour is based on the observed upstream rejection and the concrete Codex client requirement.