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

Open 💬 2 comments Opened May 19, 2026 by jamesx0416

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 ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗