Owner service · sanitized interface captures

Codex Gateway

Codex Gateway is a Ruby proxy in front of the model API. It manages multiple access configurations, selectively inspects only Codex traffic, proxies HTTP, SSE and WebSocket and accounts for usage per user. Sanitized event copies go to a bounded outbox and NATS without blocking the main Codex request.

Service — access required ↗Documentation →The source repository is private
Development and operation: 2026. Captures prepared on 8 September 2026.Version 5a8e7e338 interface screenshots

Gateway dashboard with active configuration, token lifetime and per-user aggregate usage. Visible accounts were replaced only in the DOM before capture.

01 / The task

Ruby proxy for controlled Codex access

The task was to provide several Codex clients with controlled access through one gateway, expose configuration lifetime, errors and token usage, and keep monitoring from becoming a new failure point.

Use case: The owner manages access and statistics in a closed UI; Codex clients use separate proxy credentials; Synadia receives only sanitized event copies.

Work done

  • Implemented the Ruby proxy and CONNECT routing with selective TLS inspection for Codex domains.
  • Added HTTP, SSE and WebSocket transports, streaming usage parsing and connection recovery.
  • Connected access configurations, proxy users, limits, statistics and the admin UI.
  • Added a non-blocking outbox and sanitized NATS events for Synadia Live Monitor.

02 / Implementation

What sets the implementation apart

The Gateway combines access management, streaming transport and observability in one Ruby process while keeping monitoring off the critical path. Selective TLS inspection is limited to Codex domains and event copies are sanitized before NATS, so Synadia receives live data without making NATS a dependency of Codex traffic.

Screenshots

Screens, forms, errors

Screenshots, diagrams and source evidence retain their original language; captions and descriptions are translated.

03 / Technology

Stack

Ruby MITM / HTTP / SSE / WebSocket 86.1%Ruby event observer / outbox 13.9%

Shares use Git blob bytes of the two tracked Ruby proxy and observer modules at the pinned revision. Base-image libraries are excluded. Files are assigned to one subsystem and rounded to 0.1%; this is code composition, not proficiency.

Ruby

MITM proxy, CONNECT routing and administration server.

OpenSSL

Local certificates and selective inspection of allowed traffic.

HTTP / SSE / WebSocket

Regular and streaming Codex requests, reconnect and usage.

NATS / outbox

Non-blocking delivery of sanitized monitoring events.

04 / Decisions

How the project works

  • TLS inspection is enabled only for allowed Codex hostnames; other CONNECT traffic remains a regular tunnel.
  • Client responses do not wait for NATS: unavailable monitoring uses a bounded outbox while Codex keeps working.
  • SSE and WebSocket are parsed incrementally with split-message, UTF-8 and reconnect handling.
  • Secret headers and tokens are removed before monitoring events are created.
Codex traffic and sanitized event flow
Codex traffic and sanitized event flow

05 / Verification

Demo workflows

  1. Open the protected dashboard and inspect active configuration lifetime and refresh state.
  2. Compare a proxy user’s usage with 24-hour and 7-day aggregates.
  3. Inspect HTTP, SSE and WebSocket handling and Ruby proxy state.
  4. Open proxy documentation and review TLS-inspection boundaries.

Check results

  • The live Gateway serves Codex clients and reports aggregate usage per proxy user.
  • Eight captures came from the live instance; server data was unchanged and no page errors were found.

Limitations

  • The administration UI is protected by Basic Auth; the public case contains sanitized captures only.
  • Screenshots show real aggregates, while accounts and configuration values are replaced in the DOM before capture.
  • Gateway tracing is not the source of the public broadcast; live events are sent to the separate Synadia flow.

Technical notes

Modules, API, data model, setup and check results.

Documentation →Materials ↓