app-server websocket listener lacks built-in auth; propose optional Basic Auth via env vars

Resolved 💬 3 comments Opened Mar 19, 2026 by jelasin Closed May 2, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

Summary

The experimental codex app-server --listen ws://... websocket listener currently exposes websocket upgrade and health probe endpoints without built-in authentication.

I implemented a local change to support optional HTTP Basic Auth for the websocket listener using:

  • CODEX_USERNAME
  • CODEX_PASSWORD

Problem

When app-server is bound on a non-loopback address, the websocket listener can be reachable remotely unless operators place it behind a separate proxy/TLS/auth layer.

The startup message already warns about this, but there is currently no built-in authentication for:

  • websocket upgrade requests
  • GET /readyz
  • GET /healthz

Proposed change

Add optional Basic Auth enforcement for the websocket listener:

  • if both CODEX_USERNAME and CODEX_PASSWORD are set:
  • require Authorization: Basic ... on websocket upgrades
  • require Authorization: Basic ... on /readyz
  • require Authorization: Basic ... on /healthz
  • return 401 Unauthorized with WWW-Authenticate when missing or invalid
  • if neither variable is set:
  • keep current behavior
  • if only one variable is set:
  • log a warning
  • continue without auth rather than failing startup

This keeps the current local/dev workflow unchanged while providing a minimal built-in protection mechanism for exposed websocket listeners.

Notes

  • The existing Origin rejection behavior is preserved.
  • I already have a working implementation and tests on my fork.
  • If this direction aligns with the project, I can provide a branch, patch, or PR if invited.

Testing in local implementation

  • cargo test -p codex-app-server
  • just fix -p codex-app-server
  • just fmt

View original on GitHub ↗

3 Comments

jelasin · 5 months ago

I already have a working implementation on my fork if maintainers want to review or cherry-pick it.

Branch:

Compare view:

Commit:

  • b17c0c567677595e719c0186f97d86366eeee020

If it is easier for maintainers, I can also provide a patch file or adjust the implementation based on feedback.

etraut-openai contributor · 5 months ago

We're working on adding this. See this PR for details.

etraut-openai contributor · 3 months ago

This feature request hasn't received enough upvotes, so I'm closing it.