kimi-routed turns store non-standard reasoning content (reasoning_text) in thread history — OpenAI remote compaction 400s (array_above_max_length), thread permanently bricked

[Geostigma-zero]

Summary

When a Codex thread contains turns routed to Kimi (kimi/k3, kimi/k3[1m]) through the openai-chat adapter, the thread's persisted history accumulates reasoning items carrying a non-standard content: [{type: "reasoning_text", ...}] array. Regular /v1/responses turns tolerate these items, but OpenAI's remote compaction endpoint validates strictly: it expects content on reasoning items to be an empty array and rejects the compact request with 400 array_above_max_length. From that moment the thread is permanently bricked — auto-compaction is required to continue, and every retry fails at the same index.

Environment

• opencodex 2.7.30 (npm @bitkyc08/opencodex), Windows 11 x64
• codex-cli 0.144.6 (Codex App + CLI)
• Kimi via OAuth, baseUrl: https://api.kimi.com/coding/v1, adapter openai-chat
• Thread models mixed: kimi/k3, kimi/k3[1m], gpt-5.6-sol, gpt-5.6-luna

Error

Right after "context auto-compacted", every subsequent turn fails:

Error running remote compact task: {
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "[ArrayParam] [input[201].content] [array_above_max_length] Invalid 'input[201].content': array too long. Expected an array with maximum length 0, but got an array with length 1 instead."
  },
  "status": 400
}

Three retries, same index input[201] every time.

Root-cause analysis

Inspecting the thread rollout files (~/.codex/sessions/**/rollout-*.jsonl):

• Reasoning items from native OpenAI turns (gpt-5.5 / gpt-5.6) have no content field (standard shape: summary + encrypted_content).
• Reasoning items from kimi-routed turns carry content: [{type: "reasoning_text", text: ...}] — exactly one element, matching the error's "got an array with length 1"; the first such item aligns with the rejected index.

Correlation across six threads on this machine:

Thread	Models used	reasoning items	with reasoning_text content
A (the bricked one)	gpt-5.6-sol, gpt-5.6-luna, kimi/k3	79	9
B	gpt-5.6-sol, kimi/k3	134	16
C	kimi/k3[1m] only	25	25 (all)
D	kimi/k3[1m] only	11	11 (all)
E	kimi/k3[1m] only	16	16 (all)
F (older, pre-opencodex)	gpt-5.5 only	135	0

100% correlation between kimi-via-opencodex turns and the non-standard shape; threads served only by native OpenAI models are clean.

Impact

• Any Codex thread containing kimi-routed turns will brick as soon as remote auto-compaction is needed against the OpenAI backend. The offending item persists in history, so no retry ever succeeds; the user effectively loses the thread.
• Mixing routed and native models in one long-running thread — a headline opencodex workflow — is currently unsafe.

Workaround (confirmed locally)

Stripping the content field from every reasoning item whose parts are all type: "reasoning_text" in the rollout JSONL un-bricks the thread; compaction then succeeds.

Suggestion

• Serialize translated provider reasoning in the spec-conformant shape Codex/OpenAI persist natively (e.g. summary parts, or omit content entirely) so stored history passes the compact endpoint's validation.
• Optionally sanitize/strip such items on the way out for histories that already contain them (e.g. when forwarding compact requests).

Likely related to #210, which confirms the content/reasoning_text emission shape. Happy to provide the affected rollout excerpts privately if useful.

[lidge-jun]

Fixed by #248, now merged into dev: the v1 compact endpoint (/v1/responses/compact) was forwarding thread history directly without running the existing reasoning sanitizer, so kimi-routed reasoning_text items reached OpenAI's remote compaction and triggered the 400. The compact path now sanitizes reasoning content the same way normal request building does.

This will ship with the next release from dev. Closing — please reopen if you can still reproduce after upgrading.