bug: HTTP bridge forwards unsafe WebSocket headers and can break hard-affinity 1011 retries

[mastertyko]

Pre-flight checklist

• I searched existing issues and confirmed this is not a duplicate.
• I am running a supported codex-lb version (see Releases).
• I can reproduce the problem with the steps below.

codex-lb version

Current main / source checkout.

Deployment method

From source or Docker/Compose deployments that proxy the Responses API through the HTTP bridge.

Client used against codex-lb

Direct HTTP / SDK-compatible Responses clients.

ChatGPT account plan(s) involved

Mixed pool / not plan-specific.

Model(s) involved

Responses API models that use the HTTP bridge and upstream Responses WebSocket transport.

What happened?

The HTTP Responses bridge can forward downstream HTTP-only or hop-by-hop headers when it opens the upstream Responses WebSocket. Examples include accept, accept-encoding, authorization, connection, content-type, cookie, and host.

The same path can also forward the HTTP Responses beta token (OpenAI-Beta: responses=experimental) into the upstream WebSocket handshake instead of using the Responses WebSocket beta token.

When the upstream socket closes before response.created, the hard-affinity reconnect path can also treat close code 1011 like a soft reroute and exclude the session owner account. That can replay a hard-affinity bridge session on another account instead of staying account-bound.

What did you expect to happen?

The bridge should open upstream Responses WebSockets with only WebSocket-safe upstream headers. It should preserve the Responses WebSocket beta token and not forward HTTP-only Responses beta tokens or HTTP request framing headers.

For hard-affinity bridge sessions, reconnect after upstream close 1011 should remain bound to the owning account. Soft-affinity prompt-cache reroute behavior can still skip the previous account.

Steps to reproduce

1. Start codex-lb from a current source checkout with at least one upstream account.
2. Send a streamed Responses request through the HTTP bridge with typical HTTP client headers such as accept, accept-encoding, content-type, and connection.
3. Observe the upstream Responses WebSocket handshake headers generated by the bridge.
4. Force or observe an upstream WebSocket close before response.created with close code 1011 on a hard-affinity bridge session.
5. Observe whether reconnect keeps the owner account or excludes it from account selection.

Relevant logs

No unredacted deployment logs are included here. The issue is covered by the regression tests in the linked PR.

Configuration / environment

No special configuration is required beyond the HTTP Responses bridge path.

Additional context

The linked PR adds an OpenSpec change and regression coverage for header filtering, Responses WebSocket beta normalization, and hard-affinity ownership preservation after close code 1011.