Codex responses-lite: parallel_tool_calls is hardcoded to false, so models never emit parallel tool calls

[batcave-official]

What happens

For the responses-lite models (gpt-5.6-sol / gpt-5.6-luna / gpt-5.6-terra), every upstream request is sent with parallel_tool_calls: false, so the model never emits more than one tool call per assistant turn. Claude Code's harness fully supports parallel tool_use blocks, so through the proxy all tool activity is serialized — a latency cost on tool-heavy agentic work (subagent fan-outs, multi-file reads).

Verified on v0.1.11 with traffic dumps: every *-upstream-request.json for a sol/luna session carries "parallel_tool_calls": false. Round-trip fidelity is otherwise fine — a conversation history that already contains parallel tool_use blocks with paired tool_results translates and replays correctly; the flag only suppresses emission.

Where it comes from

src/providers/codex/translate/request.rs (fe80a6b): translate_request defaults parallel_tool_calls: true, then the use_responses_lite branch forces it off:

if opts.use_responses_lite {
    ...
    out.parallel_tool_calls = false;

and uses_responses_lite matches exactly the 5.6 family, so there's no way to reach these models without the override.

Question / request

Is this a hard constraint of the responses-lite protocol (e.g. because tools are injected as developer-role AdditionalTools input items rather than the native tools field, or because the backend rejects/ignores it), or a conservative default mirroring the Codex CLI?

• If the backend accepts it: would you take a PR flipping the default, or gating it behind an opt-in (e.g. CCP_PARALLEL_TOOL_CALLS=1)?
• If the backend genuinely can't do it in lite mode: a note in the README would save others the investigation.

Happy to contribute the PR either way. Thanks for the proxy — everything else in our evaluation (streaming, effort mapping, prompt-cache keying, OAuth refresh across the 60-min boundary) checked out cleanly.