I independently hit the same root cause while debugging gateway instability on macOS, and I wanted to add a few datapoints that may help reviewers validate the fix.

What I observed locally:

• Long-running hermes gateway run --replace processes using openai-codex would start producing repeated APIConnectionError / APITimeoutError, even on tiny prompts (2-7 messages, ~5k-10k tokens).
• In the same environment, a fresh-shell hermes chat -q ... often still succeeded.
• Replaying the exact request-dump body from a failed gateway turn as a fresh streaming POST to https://chatgpt.com/backend-api/codex/responses returned HTTP 200, which strongly pointed away from payload content and toward daemon/client state.
• lsof on the gateway daemons showed stale TCP state (CLOSE_WAIT) in the long-lived process.

That matched the exact issue fixed here: _create_openai_client() was mutating caller-owned kwargs, so gateway-held self._client_kwargs could retain a concrete http_client, and later request clients were not actually fresh.

Additional note: on my side, preserving OpenAI SDK timeout / connection-limit defaults alongside the keepalive client was also helpful for keeping gateway behavior aligned with fresh-shell behavior.

For traceability, I documented the full reproduction and validation notes in #11070, and closed my duplicate PR #11072 in favor of this one.

I independently hit the same root cause while debugging gateway instability on macOS, and I wanted to add a few datapoints that may help reviewers validate the fix.

What I observed locally:

• Long-running hermes gateway run --replace processes using openai-codex would start producing repeated APIConnectionError / APITimeoutError, even on tiny prompts (2-7 messages, ~5k-10k tokens).
• In the same environment, a fresh-shell hermes chat -q ... often still succeeded.
• Replaying the exact request-dump body from a failed gateway turn as a fresh streaming POST to https://chatgpt.com/backend-api/codex/responses returned HTTP 200, which strongly pointed away from payload content and toward daemon/client state.
• lsof on the gateway daemons showed stale TCP state (CLOSE_WAIT) in the long-lived process.

That matched the exact issue fixed here: _create_openai_client() was mutating caller-owned kwargs, so gateway-held self._client_kwargs could retain a concrete http_client, and later request clients were not actually fresh.

Additional note: on my side, preserving OpenAI SDK timeout / connection-limit defaults alongside the keepalive client was also helpful for keeping gateway behavior aligned with fresh-shell behavior.

For traceability, I documented the full reproduction and validation notes in #11070, and closed my duplicate PR #11072 in favor of this one.

Thanks for the findings. Could you please verify if this PR fixes your issue?