Problem
Codex inside a Capsem VM currently cannot use the built-in OpenAI provider's Responses WebSocket transport through Capsem's MITM proxy.
Observed repro from a fresh installed-layout VM:
codex doctor
...
✓ auth auth is provided by environment
auth env vars present OPENAI_API_KEY
⚠ websocket Responses WebSocket failed
endpoint wss://api.openai.com/v1/<redacted>
handshake transport error http 400 Bad Request: Some("Capsem: WebSocket upgrades are not supported (GET /v1/responses)\n")
Running codex exec then fails with:
ERROR: Capsem: WebSocket upgrades are not supported (GET /v1/responses)
This can look like "Codex cannot find the OpenAI key", but the key path is working: OPENAI_API_KEY is injected and Codex doctor reports env auth.
Current workaround
Commit e8e6ce6d changed Capsem's generated in-VM Codex config to use a capsem-openai provider alias with:
model_provider = "capsem-openai"
[model_providers.capsem-openai]
name = "OpenAI via Capsem"
base_url = "https://api.openai.com/v1"
env_key = "OPENAI_API_KEY"
wire_api = "responses"
supports_websockets = false
That makes Codex use normal HTTPS streaming through Capsem, which already works with the existing MITM policy and telemetry path.
Desired fix
Add first-class WebSocket upgrade support in the Capsem MITM proxy so model clients that prefer or require WebSockets can work without per-client transport overrides.
Key points to design/test:
- Accept and proxy HTTP/1.1
Upgrade: websocket through the MITM path.
- Preserve policy decisions before the upstream connection is established.
- Preserve telemetry for connection lifecycle, request metadata, close/error state, and provider attribution.
- Decide what model-call evidence can be captured from WebSocket frames, and fail closed or degrade explicitly if frame interpretation is unsupported.
- Add regression tests for
GET /v1/responses WebSocket upgrade instead of the current intentional 400 websocket-not-supported path.
Acceptance criteria
- A fresh Capsem VM can run
codex doctor with the built-in OpenAI provider without the WebSocket warning caused by Capsem.
codex exec can use the built-in OpenAI provider through Capsem without requiring supports_websockets = false.
- Existing HTTP/SSE OpenAI, Anthropic, and Gemini paths remain covered and unaffected.
- Telemetry records WebSocket allow/deny/error outcomes clearly.
Problem
Codex inside a Capsem VM currently cannot use the built-in OpenAI provider's Responses WebSocket transport through Capsem's MITM proxy.
Observed repro from a fresh installed-layout VM:
Running
codex execthen fails with:This can look like "Codex cannot find the OpenAI key", but the key path is working:
OPENAI_API_KEYis injected and Codex doctor reports env auth.Current workaround
Commit
e8e6ce6dchanged Capsem's generated in-VM Codex config to use acapsem-openaiprovider alias with:That makes Codex use normal HTTPS streaming through Capsem, which already works with the existing MITM policy and telemetry path.
Desired fix
Add first-class WebSocket upgrade support in the Capsem MITM proxy so model clients that prefer or require WebSockets can work without per-client transport overrides.
Key points to design/test:
Upgrade: websocketthrough the MITM path.GET /v1/responsesWebSocket upgrade instead of the current intentional400 websocket-not-supportedpath.Acceptance criteria
codex doctorwith the built-in OpenAI provider without the WebSocket warning caused by Capsem.codex execcan use the built-in OpenAI provider through Capsem without requiringsupports_websockets = false.