app-server thread/start ignores profile model_provider from -p

Open 💬 2 comments Opened May 19, 2026 by jamesx0416
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What is the issue?

codex -p <profile> app-server does not appear to apply the selected profile's model_provider when starting a thread through JSON-RPC thread/start.

The same profile works through codex -p <profile> exec ..., but app-server starts the thread with modelProvider: "openai" and then attempts to connect to the OpenAI Responses API.

Reproduction

Given a Codex config profile named codex_lb whose model_provider is codex-lb:

codex -p codex_lb app-server

Send initialize:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"clientInfo":{"name":"manual","title":"manual","version":"0"},"capabilities":{"experimentalApi":true}}}

Send initialized:

{"jsonrpc":"2.0","method":"initialized"}

Start a thread without an explicit modelProvider:

{"jsonrpc":"2.0","id":2,"method":"thread/start","params":{"cwd":"/Users/4980/Projects/t3code","approvalPolicy":"never","sandbox":"danger-full-access"}}

Expected behavior

The thread should use the profile's configured model provider:

"modelProvider":"codex-lb"

Actual behavior

The thread starts with OpenAI instead:

"model":"gpt-5.5",
"modelProvider":"openai"

Then app-server attempts to connect to OpenAI and fails:

ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: HTTP error: 401 Unauthorized, url: wss://api.openai.com/v1/responses

Additional context

This command succeeds with the same profile, which suggests the profile itself is valid and exec respects it:

codex -p codex_lb exec --skip-git-repo-check "Say only: ok"

Output includes:

provider: codex-lb
codex: ok

So the issue seems specific to the app-server / thread/start path not inheriting the profile's model_provider.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #23310

Powered by Codex Action

adpena contributor · 1 month ago

Current Windows reproduction on codex-cli 0.144.1: the failure mode is now stronger than the original report. The profile is rejected before app-server starts.

Error: --profile only applies to runtime commands and `codex mcp`:
`codex`, `codex exec`, `codex review`, `codex resume`, `codex archive`,
`codex delete`, `codex unarchive`, `codex fork`, `codex mcp`,
`codex sandbox`, and `codex debug prompt-input`.

Reproduction:

codex -p local-compaction app-server --listen ws://127.0.0.1:4510

The same provider contract works when supplied as explicit -c overrides to app-server. I verified that path end to end:

  • app-server healthy on loopback
  • JSON-RPC initialize / thread/start / turn/start completed
  • persisted session_meta.model_provider was the custom provider
  • thread/compact/start completed
  • a second post-compaction turn completed

So app-server can consume the provider configuration; only the named profile layer is blocked. Please either restore -p for app-server or document/provide an equivalent supported named config layer for app-server daemons.