codex - ✅(Solved) Fix app-server thread/start ignores profile model_provider from -p [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#23417Fetched 2026-05-20 03:50:24
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Timeline (top)
labeled ×4commented ×1cross-referenced ×1

Error Message

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

Fix Action

Fixed

PR fix notes

PR #2756: Add Codex config profile setting

Description (problem / solution / changelog)

What Changed

Adds a minimal Codex Config profile provider setting and threads it through Codex launch paths:

  • Passes -p <profile> to Codex app-server status probes, app-server sessions, and codex exec text generation.
  • Reads the selected profile's model_provider from Codex config and passes it into app-server thread/start / thread/resume startup.
  • Avoids showing the OpenAI auth error as blocking when the profiled app-server returns models.
  • Adds focused schema/runtime tests for the new setting and launch behavior.

Why

This lets T3 Code use Codex config profiles backed by non-default providers, such as a custom provider profile.

The explicit config lookup exists because of an upstream Codex app-server bug/limitation: codex -p <profile> app-server does not apply the profile's model_provider to thread/start by default, even though codex -p <profile> exec ... does. Without passing modelProvider explicitly, app-server starts threads with modelProvider: "openai" and can hit OpenAI 401s for custom-provider profiles.

Upstream issue: https://github.com/openai/codex/issues/23417

UI Changes

Adds a small Config profile text field to the existing Codex provider settings form. Before: <img width="812" height="538" alt="Screenshot 2026-05-19 at 3 27 38 pm" src="https://github.com/user-attachments/assets/7e294b4c-4f5d-44b8-a738-98dd7a8123d8" />

After: <img width="811" height="628" alt="Screenshot 2026-05-19 at 3 26 15 pm" src="https://github.com/user-attachments/assets/97eb1661-7d64-4fb5-92bf-b3cd358379e8" />

Checklist

  • This PR is small and focused
  • I explained what changed and why
  • I included before/after screenshots for any UI changes
  • I included a video for animation/interaction changes

Verification:

  • bun fmt
  • bun lint (passes with existing warnings)
  • bun typecheck
  • cd apps/server && bun run test src/provider/Layers/CodexProvider.test.ts src/provider/Layers/CodexSessionRuntime.test.ts src/textGeneration/CodexTextGeneration.test.ts src/serverSettings.test.ts
<!-- CURSOR_SUMMARY -->

[!NOTE] Medium Risk Changes Codex provider launch/probe behavior and thread-start parameters (including auth-status determination), which can affect whether Codex sessions start and how they authenticate, but scope is limited to the Codex integration and is covered by new tests.

Overview Adds a new Codex provider setting, profileName, surfaced in the settings schema/UI and supported in settings patches.

When set, Codex commands now run with -p <profileName> for app-server probes, app-server session spawn, and codex exec text generation; session startup also reads Codex config (config/read) to extract model_provider (profile-specific first) and forwards it via modelProvider in thread/start/thread/resume.

Provider status probing is adjusted so profiled providers don’t treat requiresOpenaiAuth as blocking when non-custom models are present; tests are updated/added to validate profile propagation, modelProvider forwarding, and the auth/model readiness behavior.

<sup>Reviewed by Cursor Bugbot for commit 03a7261a21158209c140ffa3abe530770de17ba2. Bugbot is set up for automated code reviews on this repo. Configure here.</sup>

<!-- /CURSOR_SUMMARY --> <!-- Macroscope's pull request summary starts here --> <!-- Macroscope will only edit the content between these invisible markers, and the markers themselves will not be visible in the GitHub rendered markdown. --> <!-- If you delete either of the start / end markers from your PR's description, Macroscope will append its summary at the bottom of the description. -->

[!NOTE]

Add profileName config profile setting to Codex provider

  • Adds profileName to CodexSettings in settings.ts, wiring it through the provider status check, session runtime, and text generation layers.
  • When set, prepends -p {profileName} to app-server and codex exec command args, and reads profile-specific model config for thread start/resume requests.
  • Providers with a configured profile treat requiresOpenaiAuth as non-blocking when models are available, allowing the provider to report ready without OpenAI auth.
  • Behavioral Change: unauthenticated Codex accounts with a profile set no longer block provider readiness on OpenAI auth.
<!-- Macroscope's review summary starts here -->

<sup><a href="https://app.macroscope.com">Macroscope</a> summarized 03a7261.</sup>

<!-- Macroscope's review summary ends here -->
<!-- macroscope-ui-refresh --> <!-- Macroscope's pull request summary ends here --> <!-- This is an auto-generated comment: release notes by coderabbit.ai -->

Summary by CodeRabbit

  • New Features

    • Added optional "Config profile" setting for the Codex provider, enabling profile-scoped configuration and model-provider selection; the Codex helper now forwards a selected profile to the Codex server process.
  • Tests

    • Added and updated tests to validate profile handling, model-provider propagation, probe behavior, and settings patch/encoding for Codex profile.
<!-- review_stack_entry_start -->

Review Change Stack

<!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai -->

Changed files

  • apps/server/src/provider/Layers/CodexAdapter.test.ts (modified, +26/-0)
  • apps/server/src/provider/Layers/CodexAdapter.ts (modified, +1/-0)
  • apps/server/src/provider/Layers/CodexProvider.ts (modified, +10/-3)
  • apps/server/src/provider/Layers/CodexSessionRuntime.test.ts (modified, +3/-0)
  • apps/server/src/provider/Layers/CodexSessionRuntime.ts (modified, +20/-1)
  • apps/server/src/provider/Layers/ProviderInstanceRegistryLive.test.ts (modified, +1/-0)
  • apps/server/src/provider/Layers/ProviderRegistry.test.ts (modified, +62/-0)
  • apps/server/src/serverSettings.test.ts (modified, +5/-0)
  • apps/server/src/textGeneration/CodexTextGeneration.test.ts (modified, +22/-1)
  • apps/server/src/textGeneration/CodexTextGeneration.ts (modified, +1/-0)
  • apps/web/src/components/KeybindingsToast.browser.tsx (modified, +1/-0)
  • apps/web/src/components/settings/ProviderSettingsForm.test.ts (modified, +1/-0)
  • packages/contracts/src/settings.ts (modified, +5/-0)

Code Example

codex -p codex_lb app-server

---

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

---

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

---

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

---

"modelProvider":"codex-lb"

---

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

---

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

---

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

---

provider: codex-lb
codex: ok
RAW_BUFFERClick to expand / collapse

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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

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

"modelProvider":"codex-lb"

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING