Skip to content

Support Responses WebSocket traffic through the Capsem MITM proxy #61

@ebursztein

Description

@ebursztein

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions