ネイティブのメインログインプロファイル

ネイティブログインと Pool の選択は別

Codex Set → Multi-auth で、メインアカウントカードのすぐ下にある Native main login パネルの Manage main login を開きます。同じパネルは Providers のアカウント画面でもメインカードの横に表示されます。管理するのは物理的な Codex ログインであり、次の Pool リクエストに使うアカウントではありません。Integrations タブの追加や、既存の Pool コントロールの置き換えは行いません。

表示される Effective CODEX_HOME は OpenCodex サーバーのものです。リモートのダッシュボードでは、ブラウザーとは別のコンピューターを指す場合があります。Registered active profile は暗号化されたプロファイルストアに記録された所有者です。サーバーは切り替え前に物理的なログインを検証します。そのため、OpenCodex の外でログインを変更すると、黙って上書きされる代わりに所有者不一致のエラーになる場合があります。

保存と切り替え

既存のアプリログインを登録するには Save current as profile を使います。登録済みのアクティブログインに対して実行するとラベルが更新され、新しいアカウントは登録されません。プロファイルの切り替えには、対応するファイル形式の認証情報ストアと、利用可能な OS のキーストアが必要です。コントロールが使えない理由は診断コードに示されます。キーストアや所有者のエラーを回避するために Pool の認証情報をネイティブログインファイルにコピーしないでください。メインカードの既存のネイティブデバイス再認証が進行中は、このパネルは無効になります。

保存済みの非アクティブプロファイルの横にある Switch を選びます。対象のラベルとサーバー側のホームを確認し、そのホームを使うネイティブ Codex を停止してから、停止確認をチェックして送信します。確認前に認証情報の変更は送信されません。パネルは送信直前に現在のホーム、アクティブな所有者、復旧状態を読み直します。状態が変わっていた場合は、改めて確認してください。ロック、プロセス確認、処理中リクエストの排出、アクティベーション、ロールバックについては、既存のバックエンドが最終的な権限を持ちます。

成功後は表示された再起動要件に従い、そのホームでネイティブ Codex を開き直します。パネルはプロファイル状態を再取得し、既存のアカウントコントローラーを更新します。Pool の選択や設定の変更 API は呼ばず、プロバイダーキー、タスク、履歴も編集しません。既存のバックエンドは CLI と同様に、ネイティブの __main__ ID を引き続き照合します。

復旧と以前のプロファイル

次の操作は異なります。

• Recover interrupted change は未完了のバックエンドトランザクションを照合します。Restore pending transaction はそのトランザクションのロールバックを要求します。いずれも別途停止確認が必要です。プロファイル一覧が破損して読み取れなくても、診断で保留中の復旧が報告される場合は利用できます。
• 切り替え成功後の Return to previously displayed は、通常の確認付き切り替え手順を使い、切り替え前に表示されていたプロファイルを選びます。このショートカットはページのメモリにだけ保持され、ホームと想定されるアクティブ所有者に限定されます。ページ再読み込みやプロキシまたは所有者の変更で消えます。API はトランザクションの元を返さないため、サーバーが検証した取り消し履歴ではありません。事前確認と切り替えの間に別の操作者がログインを変更した可能性があります。再読み込み後は、目的の保存済みプロファイルを直接選んでください。

ネットワークエラーだけでは、書き込みが失敗またはロールバックされたとは判断できません。パネルは、応答が失われた場合も含め、変更を送信した後にサーバーの状態を再取得し、自動再試行しません。更新に失敗しても、成功した変更を取り消し済みとは報告しません。次の操作の前に更新して診断を確認してください。既存の ocx account main doctor コマンドでサーバー側の診断を確認できます。

この段階の範囲

このパネルは、既存の /api/native-main-profiles 境界を使って、既存プロファイルの一覧表示、登録、切り替え、復旧を行います。ログインプロセスの起動や、一時的な書き込みトークンの公開は行いません。別のネイティブログインの追加には、引き続き ocx account main add CLI を使います。ブラウザーでの登録は issue #3417 の別の後続作業です。現在のメインスロットの既存のデバイス再認証も別の手順であり、このパネルには置き換わりません。

プロファイルデータはブラウザーストレージに書き込まれません。クライアントは公開フィールドだけを表示し、生のサーバーメッセージではなく許可されたエラーコードを示し、アプリケーションの既存の認証済み fetch ラッパーを使います。バックエンドの管理認証、GUI セッションと CSRF、ルート受け入れの検査は変わりません。