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.
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, errorsScreenshots, diagrams and source evidence retain their original language; captions and descriptions are translated.
03 / Technology
Stack
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.
05 / Verification
Demo workflows
- Open the protected dashboard and inspect active configuration lifetime and refresh state.
- Compare a proxy user’s usage with 24-hour and 7-day aggregates.
- Inspect HTTP, SSE and WebSocket handling and Ruby proxy state.
- 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 ↓