Support selecting a config profile for app-server and Desktop via environment variable

Open 💬 2 comments Opened Aug 12, 2026 by sailorfeng
💡 Likely answer: A maintainer (kvokka, contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

Codex App / app-server

What feature would you like to see?

Please add a supported way to select a named configuration profile for codex app-server and the Codex Desktop app at process startup through an environment variable, for example:

CODEX_CONFIG_PROFILE=work

The selected profile should use the existing profile semantics:

$CODEX_HOME/config.toml
  overlaid by
$CODEX_HOME/work.config.toml

Profiles can currently be selected with --profile <name> for supported CLI runtime commands. However, app-server does not accept --profile, and the Desktop app starts app-server internally without a supported profile selection mechanism. The Desktop app-server child process already inherits its parent environment, so an environment-variable entry point would allow launchers and shortcuts to select a profile without changing CODEX_HOME or modifying the Desktop app.

Suggested behavior:

  • Read a dedicated environment variable such as CODEX_CONFIG_PROFILE when app-server starts.
  • Resolve and validate the name using the same ProfileV2Name and profile-layer loading code used by --profile.
  • Layer $CODEX_HOME/<name>.config.toml over the base user config.
  • Keep the existing behavior unchanged when the variable is unset.
  • If both a future explicit app-server flag and the environment variable are supplied, let the explicit flag take precedence.
  • Reject invalid or missing profile names with a clear startup error.
  • Expose the active profile through an existing diagnostic surface such as initialize or config/read.

A primary use case is switching between different model/provider configurations while continuing to share the same Codex home, authentication state, projects, threads, history, skills, and plugins.

Expected workflow:

launcher sets CODEX_CONFIG_PROFILE
  -> launches Codex Desktop
  -> Desktop starts codex app-server
  -> app-server loads config.toml plus the selected profile layer

This only requests startup-time profile selection. It does not require runtime hot reload, account isolation, or a profile-switching UI.

Additional information

The current app-server launch path uses default loader overrides, while the supported profile path is constructed through the existing profile loader helpers. Adding a narrowly scoped environment-variable mapping at app-server startup appears sufficient and would avoid using separate CODEX_HOME directories.

Related issues:

  • #23417 reports app-server not applying a profile passed with -p; current versions reject --profile for app-server entirely.
  • #3860 requests broader dynamic profile switching and hot reload. This request is intentionally narrower: startup-time selection for app-server/Desktop using the existing profile file format.

No credentials, local paths, account details, or private configuration values are included in this report.

View original on GitHub ↗

2 Comments

claell · 5 days ago

Also affected by this on Windows with multiple custom providers.

  • CLI codex --profile <name> works for per-provider separation and keeps the default OpenAI provider untouched.
  • Desktop currently has no profile selection (as described). Switching the active model_provider in config.toml hides other provider buckets in the sidebar/history, even though sessions remain on disk. A persistent CODEX_HOME split is not desirable for this case.

An env-var like CODEX_CONFIG_PROFILE at app-server/Desktop startup as proposed would allow Desktop to keep the same separation as CLI without overwriting the global config.

Related filtering discussion in #15494.

kvokka contributor · 2 days ago

Since it's related, wanted to add that CODEX_CONFIG_PROFILE would be nice to have for codex exec or codex commands too, since now it's required to hack with aliases.

So, a wider scope if this issue resolution is better for consistency, at least