lidge-jun · smileBeda · Aug 27, 2026 · coderabbitai · Aug 28, 2026
@@ -180,8 +180,8 @@ d'abord depuis le shell d'origine. Définissez ensuite `CODEX_HOME` sur le répe
 En mode fournisseur dédié, `requires_openai_auth = true` maintient les surfaces de l'application et de la TUI
 Codex soumises à un compte, comme dans Codex natif. opencodex sert également `/v1/responses` par WebSocket. Le
 fournisseur dédié n'annonce `supports_websockets = true` que lorsque `"websockets": true`. Sur l'interface de
-bouclage, le fournisseur intégré de Codex peut tenter WebSocket en premier ; si cette fonction est désactivée,
-le proxy renvoie `426` et Codex se rabat sur HTTP/SSE.
+bouclage, le fournisseur intégré de Codex peut tenter WebSocket indépendamment de cette annonce ; le proxy
+accepte donc une mise à niveau valide dans les deux modes.
 
 ## Identité et historique du fil de discussion
 

@@ -85,7 +85,7 @@ Les implémentations OAuth se trouvent dans `oauth/`. Les jetons d’accès sont
 
 ## Transport et compactage
 
-Par défaut, `server/index.ts` sert HTTP/SSE sur `/v1/responses`. Si Codex tente une mise à niveau WebSocket de Responses alors que `websockets` vaut `false`, opencodex renvoie `426 upgrade_required` ; Codex revient alors à HTTP pour cette session. Lorsque `"websockets": true` est défini, le même point de terminaison accepte la mise à niveau et utilise le pont WebSocket.
+`server/index.ts` sert HTTP/SSE et les mises à niveau WebSocket sur `/v1/responses`. Le réglage `websockets` contrôle l’annonce de cette capacité pour les lignes routées du catalogue et des fournisseurs. Le fournisseur OpenAI intégré de Codex peut tenter une mise à niveau dès que `openai_base_url` pointe vers le proxy ; les mises à niveau valides restent donc acceptées lorsque l’annonce est désactivée. `426 upgrade_required` est réservé à un échec de mise à niveau.
 
 Indépendamment de ce réglage côté client, les requêtes canoniques transmises à ChatGPT avec `stream: true` à la racine peuvent utiliser le transport WebSocket en amont de Codex avec une version stable de Bun 1.4.0 ou ultérieure. La version intégrée Bun 1.3.14, les préversions et les identités de runtime impossibles à vérifier utilisent HTTP/SSE. Les réponses WS en amont qui réussissent conservent le contrat SSE en aval et contournent `tee()` au moyen d’un relais borné à lecteur unique et avide (4 MiB par trame brute/enveloppée et une file de production de 8 MiB). Le dépassement de la file ferme la connexion en amont et émet en aval un événement terminal `response.failed`, suivi de `[DONE]`.
 

@@ -143,9 +143,10 @@ Une trame d'échauffement avec `generate: false` n'appelle pas d'amont. Il renvo
 `response.created` suivi de `response.completed`, tous deux avec un identifiant de réponse vide et aucune sortie.
 
 :::note
-Lorsque les WebSockets sont désactivés, une tentative de mise à niveau reçoit HTTP 426 avec le code
-`upgrade_required`. Codex traite ce résultat de poignée de main comme un signal de retour à HTTP pour le
-session. Il ne s’agit pas d’un échec du modèle routé.
+Lorsque l’annonce WebSocket est désactivée, les lignes routées du catalogue omettent l’indicateur de
+capacité. Le fournisseur OpenAI intégré peut néanmoins tenter une mise à niveau après le remplacement
+de `openai_base_url` ; le proxy accepte donc les mises à niveau valides dans les deux modes. HTTP 426
+est réservé à une mise à niveau qui ne peut pas être effectuée.
 :::
 
 ## `POST /v1/chat/completions`
@@ -295,7 +296,7 @@ Les erreurs utilisent l'enveloppe du dialecte client lorsque cela est nécessair
 | 403 | `origin_rejected` | Une demande de plan de données Réponses/OpenAI ou une mise à niveau WebSocket provient d'une origine non autorisée |
 | 503 | `combo_unavailable` | Chaque cible du combo sélectionné est indisponible, en temps de recharge, désactivée ou autrement inéligible |
 | 400 | `unreadable_encrypted_agent_task` | Une tâche de travail v2 chiffrée n'a pas de cible native éligible pouvant la consommer |
-| 426 | `upgrade_required` | Le transport Réponses WebSocket est désactivé ou la mise à niveau a échoué ; utiliser HTTP |
+| 426 | `upgrade_required` | Une mise à niveau WebSocket de Responses n’a pas pu être effectuée ; utiliser HTTP |
 
 Les échecs d'origine Anthropic sont restitués dans l'enveloppe d'erreur de Anthropic, donc le rejet d'origine est un
 403 `permission_error` sur ce dialecte plutôt que sur le corps `origin_rejected` de style OpenAI.

@@ -12,6 +12,17 @@ plus `openai-apikey/<model>` for the configured API key. Pool includes main plus
 Direct uses only the caller/main bearer. The routes do not fall back to one another. Shipped v1
 configs migrate to marker 2 and preserve `config.json.pre-openai-tiers-v2.bak` for manual restore.
 
+Codex may keep its main ChatGPT login in the operating-system keyring instead of
+`$CODEX_HOME/auth.json`. OpenCodex does not inspect that keyring or launch Codex to infer login
+presence. Before the first successful request through the proxy, the dashboard therefore explains
+that account type and quota are not available yet instead of claiming either authentication or
+sign-out. In Pool mode, a native Codex request uses the caller-owned bearer already attached to that
+request for the main account. After a successful upstream response, OpenCodex keeps only non-secret
+display metadata and parsed quota values in memory. It can make one bounded, read-only usage lookup
+with that request-scoped bearer to learn fields absent from response headers, such as reset-credit
+count, but it never retains the credential. Reset-credit actions still require a file-backed main
+credential. Other clients still need a file-backed main credential or an added Pool account.
+
 ## Config injection
 
 `ocx init`, `ocx start`, and `ocx sync` call the injector. On the default loopback bind, it keeps
@@ -173,8 +184,8 @@ home, unset `ORCA_CODEX_HOME`, rerun sync/restore, and install the service again
 In dedicated-provider mode, `requires_openai_auth = true` keeps Codex App/TUI account-gated surfaces
 aligned with native Codex. opencodex also serves `/v1/responses` over WebSocket. The dedicated
 provider advertises `supports_websockets = true` only when `"websockets": true`; on loopback Codex's
-built-in provider may try WebSocket first, and a disabled proxy returns `426` so Codex falls back to
-HTTP/SSE.
+built-in provider may try WebSocket regardless of that advertisement, so the proxy accepts a valid
+upgrade in either mode.
 
 ## Thread identity and history
 

@@ -112,7 +112,7 @@ WSL では、`CODEX_HOME` が設定されておらず、Linux `~/.codex/config.t
 
 Windows では、ChatGPT/Codex アプリが `%USERPROFILE%\\.codex` を読み取りながら、Orca シェルは `CODEX_HOME` と `ORCA_CODEX_HOME` の両方を Orca のバンドルされたランタイム ホームに設定できます。 `ocx status` および `ocx doctor` は、この正確な不一致について警告し、編集されたターゲット パスを出力します。バックグラウンド サービスが Orca シェルからインストールされている場合は、最初に元のシェルからアンインストールし、次に `CODEX_HOME` をアプリ ホームに設定し、`ORCA_CODEX_HOME` の設定を解除し、同期/復元を再実行して、サービスを再度インストールします。
 
-専用プロバイダー モードでは、`requires_openai_auth = true` は Codex App/TUI アカウント ゲート サーフェスをネイティブ Codex と一致させます。 opencodex は WebSocket 経由で `/v1/responses` も提供します。専用プロバイダーは、`"websockets": true` の場合にのみ `supports_websockets = true` をアドバタイズします。ループバック時 Codex の組み込みプロバイダーは最初に WebSocket を試行し、無効になったプロキシが `426` を返すため、Codex は HTTP/SSE にフォールバックします。
+専用プロバイダー モードでは、`requires_openai_auth = true` は Codex App/TUI アカウント ゲート サーフェスをネイティブ Codex と一致させます。opencodex は WebSocket 経由で `/v1/responses` も提供します。専用プロバイダーは、`"websockets": true` の場合にのみ `supports_websockets = true` をアドバタイズしますが、ループバックでは Codex の組み込みプロバイダーがその通知に関係なく WebSocket を試行することがあります。そのため、プロキシはどちらのモードでも有効なアップグレードを受け入れます。
 
 ## スレッドのアイデンティティと履歴
 

@@ -95,7 +95,7 @@ HTTP の境界は `server/index.ts` が担い、Responses データプレーン
 
 ## 伝送と compaction
 
-`server/index.ts` はデフォルトで `/v1/responses` を HTTP/SSE で提供します。`websockets` が `false` の状態で Codex が Responses WebSocket アップグレードを試みると、opencodex は `426 upgrade_required` を返し、Codex はそのセッションで HTTP にフォールバックします。`"websockets": true` を設定すると同じエンドポイントがアップグレードを受け入れ WebSocket ブリッジを使います。
+`server/index.ts` は `/v1/responses` で HTTP/SSE と WebSocket アップグレードを提供します。`websockets` 設定は、ルーティングされたカタログおよびプロバイダー行での機能通知を制御します。Codex の組み込み OpenAI プロバイダーは `openai_base_url` がプロキシを指すとアップグレードを試行することがあるため、通知が無効でも有効なアップグレードは受け入れられます。`426 upgrade_required` はアップグレードに失敗した場合にのみ使用されます。
 
 Codex コンテキスト compaction はルーティングされたモデルでも動作します。`server/responses/compact.ts` は
 `POST /v1/responses/compact` を内部ルーティング要約ターンとして扱い、圧縮されたヒストリーを返します。

@@ -108,7 +108,7 @@ provider events → internal adapter events → client dialect
 `generate: false` のウォームアップ フレームはアップストリームを呼び出しません。これは、合成 `response.created` に続いて `response.completed` を返します。両方とも空の応答 ID を持ち、出力はありません。
 
 :::note
-WebSocket が無効になっている場合、アップグレード試行ではコード `upgrade_required` の HTTP 426 を受信します。 Codex は、そのハンドシェイクの結果を、セッションの HTTP にフォールバックする信号として扱います。失敗したモデルターンではありません。
+WebSocket の通知が無効な場合、ルーティングされたカタログ行では機能フラグが省略されます。ただし、`openai_base_url` の上書き後は組み込み OpenAI プロバイダーがアップグレードを試行することがあるため、プロキシはどちらのモードでも有効なアップグレードを受け入れます。HTTP 426 はアップグレードを完了できない場合にのみ使用されます。
 :::
 
 ## `POST /v1/chat/completions`
@@ -214,7 +214,7 @@ Responses-family および Chat リクエストは、プロバイダーまたは
 | 403 | `origin_rejected` | Responses/OpenAI データプレーン リクエストまたは WebSocket アップグレードが、許可されていないオリジンから送信されました。
 | 503 | `combo_unavailable` |選択したコンボ内のすべてのターゲットは使用不可、クールダウン中、無効、またはその他の理由で不適格です。
 | 400 | `unreadable_encrypted_agent_task` |暗号化された v2 ワーカー タスクには、それを使用できる適格なネイティブ ChatGPT ターゲットがありません。
-| 426 | `upgrade_required` |応答 WebSocket トランスポートが無効になっているか、アップグレードが失敗しました。 HTTP を使用する |
+| 426 | `upgrade_required` | Responses WebSocket のアップグレードを完了できませんでした。HTTP を使用してください |
 
 Anthropic オリジンの失敗は Anthropic のエラー エンベロープでレンダリングされるため、オリジンの拒否は OpenAI スタイルの `origin_rejected` 本体ではなく、その方言上の 403 `permission_error` になります。
 

@@ -104,7 +104,7 @@ WSL에서는 `CODEX_HOME`이 비어 있고 Linux `~/.codex/config.toml`도 없
 
 Windows에서 Orca shell은 `CODEX_HOME`과 `ORCA_CODEX_HOME`을 Orca의 번들 런타임 home으로 설정할 수 있지만, ChatGPT/Codex app은 여전히 `%USERPROFILE%\\.codex`를 읽습니다. `ocx status`와 `ocx doctor`는 이 정확한 불일치를 경고하고, 경로는 가린 채 대상 home을 출력합니다. 해당 Orca shell에서 background service를 설치했다면 먼저 원래 shell에서 uninstall하고, `CODEX_HOME`을 app home으로 설정한 뒤 `ORCA_CODEX_HOME`을 해제하고, sync/restore를 다시 실행한 다음 service를 다시 설치하세요.
 
-전용 provider 모드의 `requires_openai_auth = true`는 Codex App/TUI의 계정 게이트 화면을 네이티브 Codex와 같은 조건으로 맞춥니다. opencodex는 `/v1/responses`도 WebSocket으로 제공합니다. 전용 provider는 `"websockets": true`일 때만 `supports_websockets = true`를 광고합니다. loopback에서는 Codex의 빌트인 provider가 먼저 WebSocket을 시도할 수 있으며, 비활성화된 proxy는 `426`을 반환해서 Codex가 HTTP/SSE로 fallback합니다.
+전용 provider 모드의 `requires_openai_auth = true`는 Codex App/TUI의 계정 게이트 화면을 네이티브 Codex와 같은 조건으로 맞춥니다. opencodex는 `/v1/responses`도 WebSocket으로 제공합니다. 전용 provider는 `"websockets": true`일 때만 `supports_websockets = true`를 광고하지만, loopback에서는 Codex의 빌트인 provider가 이 광고와 무관하게 WebSocket을 시도할 수 있으므로 proxy는 두 모드 모두에서 유효한 업그레이드를 허용합니다.
 
 ## 스레드 식별자와 대화 기록
 

@@ -114,10 +114,10 @@ Responses 항목 타입으로 구분됩니다 — 따라서 MCP 네임스페이
 
 ## 전송과 compaction
 
-`server/index.ts`는 기본적으로 `/v1/responses`를 HTTP/SSE로 제공합니다. `websockets`가 `false`인
-상태에서 Codex가 Responses WebSocket 업그레이드를 시도하면 opencodex는 `426 upgrade_required`를
-반환하고, Codex는 해당 세션에서 HTTP로 폴백합니다. `"websockets": true`가 설정되면 같은
-엔드포인트가 업그레이드를 받아들이고 WebSocket 브리지를 사용합니다.
+`server/index.ts`는 `/v1/responses`에서 HTTP/SSE와 WebSocket 업그레이드를 제공합니다. `websockets`
+설정은 라우팅된 카탈로그 및 provider 행의 기능 광고를 제어합니다. Codex의 내장 OpenAI provider는
+`openai_base_url`이 proxy를 가리키면 업그레이드를 시도할 수 있으므로 광고가 꺼져 있어도 유효한
+업그레이드는 허용됩니다. `426 upgrade_required`는 업그레이드에 실패했을 때만 사용됩니다.
 
 이 클라이언트 설정과 별개로, 루트 `stream: true`인 canonical ChatGPT forward 요청은
 stable Bun 1.4.0 이상에서 Codex 업스트림 WebSocket을 사용할 수 있습니다. 번들 Bun 1.3.14,

@@ -138,8 +138,9 @@ queue overflow 시 downstream에는 terminal `response.failed` 이벤트와 `[DO
 `response.created` 뒤에 `response.completed`를 반환합니다.
 
 :::note
-WebSockets가 비활성화되어 있으면 업그레이드 시도는 `upgrade_required` 코드와 함께 HTTP 426을 받습니다.
-Codex는 그 핸드셰이크 결과를 해당 세션에서 HTTP로 되돌아가라는 신호로 처리합니다. 모델 턴 실패가 아닙니다.
+WebSocket 광고가 비활성화되면 라우팅된 카탈로그 행에서 기능 플래그가 생략됩니다. 하지만
+`openai_base_url`이 재정의된 뒤에는 내장 OpenAI provider가 업그레이드를 시도할 수 있으므로 proxy는
+두 모드 모두에서 유효한 업그레이드를 허용합니다. HTTP 426은 업그레이드를 완료할 수 없을 때만 사용됩니다.
 :::
 
 ## `POST /v1/chat/completions`
@@ -266,7 +267,7 @@ data-plane key는 management credential이 아닙니다. management API는 별
 | 403 | `origin_rejected` | Responses/OpenAI data-plane 요청 또는 WebSocket 업그레이드가 허용되지 않은 origin에서 들어왔습니다 |
 | 503 | `combo_unavailable` | 선택한 combo의 모든 대상이 사용할 수 없거나, cooldown 중이거나, 비활성화되어 있거나, 다른 이유로 부적합합니다 |
 | 400 | `unreadable_encrypted_agent_task` | 암호화된 v2 worker task를 소비할 수 있는 적격 네이티브 ChatGPT 대상이 없습니다 |
-| 426 | `upgrade_required` | Responses WebSocket transport가 비활성화되어 있거나 업그레이드에 실패했습니다. HTTP를 사용하십시오 |
+| 426 | `upgrade_required` | Responses WebSocket 업그레이드를 완료할 수 없습니다. HTTP를 사용하십시오 |
 
 Anthropic-origin 실패는 Anthropic의 error envelope로 렌더링됩니다. 따라서 해당 방언에서 origin 거부는
 OpenAI 스타일 `origin_rejected` body가 아니라 403 `permission_error`입니다.

@@ -138,10 +138,10 @@ diagnostics.
 
 ## Transport and compaction
 
-`server/index.ts` serves HTTP/SSE on `/v1/responses` by default. If Codex attempts a Responses
-WebSocket upgrade while `websockets` is `false`, opencodex returns `426 upgrade_required`; Codex then
-falls back to HTTP for that session. When `"websockets": true` is set, the same endpoint accepts the
-upgrade and uses the WebSocket bridge.
+`server/index.ts` serves HTTP/SSE and WebSocket upgrades on `/v1/responses`. The `websockets` setting
+controls capability advertisement for routed catalog/provider rows. Codex's built-in OpenAI
+provider may attempt an upgrade whenever `openai_base_url` points at the proxy, so valid upgrades
+remain accepted when advertisement is off; `426 upgrade_required` is reserved for a failed upgrade.
 
 Independently of that client-facing setting, canonical ChatGPT forward requests with root-level
 `stream: true` may use Codex's upstream WebSocket transport on stable Bun 1.4.0 or newer.

@@ -164,9 +164,10 @@ A warmup frame with `generate: false` does not call an upstream. It returns a sy
 `response.created` followed by `response.completed`, both with an empty response id and no output.
 
 :::note
-When WebSockets are disabled, an upgrade attempt receives HTTP 426 with code
-`upgrade_required`. Codex treats that handshake result as a signal to fall back to HTTP for the
-session. It is not a failed model turn.
+When WebSocket advertisement is disabled, routed catalog rows omit the capability flag. The
+built-in OpenAI provider can still attempt an upgrade after `openai_base_url` is overridden, so the
+proxy accepts valid upgrades in either mode. HTTP 426 is reserved for an upgrade that cannot be
+completed.
 :::
 
 ## `POST /v1/chat/completions`
@@ -316,7 +317,7 @@ Errors use the client dialect's envelope where needed, but these status/code mea
 | 403 | `origin_rejected` | A Responses/OpenAI data-plane request or WebSocket upgrade came from a disallowed origin |
 | 503 | `combo_unavailable` | Every target in the selected combo is unavailable, in cooldown, disabled, or otherwise ineligible |
 | 400 | `unreadable_encrypted_agent_task` | An encrypted v2 worker task has no eligible native ChatGPT target that can consume it |
-| 426 | `upgrade_required` | The Responses WebSocket transport is disabled or the upgrade failed; use HTTP |
+| 426 | `upgrade_required` | A Responses WebSocket upgrade could not be completed; use HTTP |
 
 Anthropic-origin failures are rendered in Anthropic's error envelope, so the origin rejection is a
 403 `permission_error` on that dialect rather than the OpenAI-style `origin_rejected` body.