codex app server update and remote connection_ja - kkamegawa/vsextensionforcodex GitHub Wiki

Codex App Server 更新対応とリモート接続

English

2026-09-20 に承認された計画。実装は親 Issue #149 と7件の子 Issue で追跡する。

2026-09-30 改定: 対象契約を Codex CLI 0.159.1、回帰比較の基準を 0.155.1 に変更した。Codex のモデル一覧はクライアントのバージョンごとに配信されるためである(例: gpt-6.1-sol は 0.159.1 以降でのみ表示される)。リモート接続は Phase 2 と Phase 3 の項目が完了するまで Preview として提供する。

2026-10-04 改定: リモートモードは Phase 4 が完了し、上流の WebSocket 転送が実験的でなくなるまで Preview を維持する。Phase 3 は共通のマッパー、物理境界、所有者パーティションを提供し、まだ存在しない利用箇所は Phase 4 と Phase 6 が提供する(Phase 3 を参照)。

2026-10-04 改定: Phase 4 は一時的な切断だけを復旧対象とし、自動試行は最大5回です。再接続後の所有者継続性は証明できないため、以前の下書き/設定 snapshot をメモリ内に隔離し、明示的な接続/profile 確認、会話選択、その後の復元または破棄を必須とします。履歴は読み取り専用のページ取得とし、選択した現在所有者の thread をユーザーが明示的に Join するまで Resume しません。現在の Worker 契約 v18 から Phase 4 で v19 へまとめて更新し、Phase 5 は v19 の次に利用可能な version を使用します。添付通知は identity の無効化だけを行い、bounded list 応答の payload は inert metadata として保持します。保存済み添付の操作は Phase 6/#155 の担当です。

2026-10-08 改定: Phase 6 は Issue #155 の承認済み計画 App Server 日常機能 で詳細化した(sandbox 外の明示 shell、client 所有の保存添付 payload registry、型付き結果と mapping 済みファイル操作、ローカル限定の Windows sandbox setup)。

2026-10-09 改定: PR #170 で Phase 6 の実装と自動検証が完了し、Issue #155 は close 済み。未完了の Experimental Instance 表示/アクセシビリティ受入は Issue #156 の Local-required として引き継ぐ。Phase 7 は承認済み統合リリース検証に従う。

概要

Visual Studio 拡張機能の既存 C#/codex app-server 連携を CLI 0.159.1 の契約へ更新し、起動済みのリモート App Server へ安全かつ明示的に接続できるようにする。ローカル stdio は既定として維持する。厳密な要求振り分け、イベント順序の安全性、リモート転送、ルート対応付けと認証主体ごとの状態分離、再接続と履歴復旧、保存済みスレッド添付の復旧/操作、非同期質問と範囲を限定した権限、未対応の本人確認と秘密入力の明示的拒否、MCP 対話と認証復旧、Gateway OAuth、日常利用イベント、shell 実行、型付き成果物、Windows sandbox 状態、統合リリース検証を対象とする。

背景と判断

この拡張機能はすでに codex app-server を利用しているため、非推奨 MCP Server からの移行は不要である。Python SDK の .params や HookMetadata.root の変更も、この C# リポジトリには直接影響しない。一方、イベント順序、履歴読み取り、要求形式、capability の挙動、エラー処理は影響するため、App Server 契約に照らして検証する。

承認済みの運用モデルは次のとおり。

  • Extension → ローカル Worker を維持する。Worker 内でローカル stdio または WebSocket を選択し、JSON-RPC の振り分け、制限、未完了要求の終了、シャットダウン処理を転送方式間で共有する。
  • ローカル stdio を既定とし、子プロセスを所有する。
  • リモートプロファイルは起動済みサーバーへ接続する。サーバーの起動・更新、SSH/トンネル管理、ファイル同期は外部の責務とする。
  • 上流の WebSocket が実験的位置付けであるため、リモート転送は明示的に有効化する。
  • Visual Studio ホストとリモートサーバーは同じ作業ツリーを参照できるものとする。設定したローカルルートとサーバールートを対応付け、拡張機能はファイル同期しない。
  • リモートホストには wss を使用する。平文 ws は loopback に限定する。Bearer トークンはファイルから読み取り、証明書検証は無効化できない。

優先度とトラッキング

優先度 項目 トラッキング
最優先 要求を厳密に振り分け、未知の要求を汎用承認へ流さない #150
最優先 接続世代とターン順序の競合を解消する #150
高 CLI 0.159.1 対象スキーマ、0.155.1 回帰比較、初期化メタデータ、capability 宣言・判定 #150
高 安全なリモート接続、接続所有権、診断、読み取り専用再試行 #151
高 ローカル/サーバーパス対応付け、接続先/アカウント/認証主体/ルートごとの状態分離 #152
高 再接続、下書き保持、ページ履歴と添付復旧、配送不明な変更操作の扱い #153
高 非同期質問、権限の部分許可、秘密/本人確認要求の明示拒否、MCP form/認証回復、ローカル Gateway OAuth #154
高 計画/スレッド/設定/モデル/MCP 状態、保存済み添付操作、型付き成果物表示 #155
中 モデル modality、推論量、明示的 shell 実行、独立した timeout #155
中 ローカル Windows sandbox 初期設定状態、対応付け済み画像/ファイル操作 #155
リリース条件 契約、競合、復旧、リモート、対話、UI、ビルド、配布物、Experimental Instance の証跡 #156

アーキテクチャ・セキュリティの不変条件

  • App Server からの全メッセージを信頼しない入力として扱う。表示テキストをサニタイズし、ログを秘匿化し、テキスト、配列、履歴ページ、コマンド出力、画像プレビューに上限を設ける。
  • 破壊的操作は既存の承認ポリシーを経由させる。
  • 実装済みクライアント capability、既知の契約、読み取り専用 API の結果、-32601 を組み合わせて機能対応を判定する。対応確認だけのために変更系 API を呼ばない。
  • 配送結果が不明な場合、ユーザー入力、承認回答、MCP 送信、shell コマンド、その他の変更操作を自動再送しない。
  • 接続/WebSocket 状態、スキル、モデル、使用量、承認記録、選択中会話、下書き、添付、復元履歴を、接続プロファイル、アカウント、認証主体、作業ルートごとに分離する。
  • アカウントまたは認証主体が変わった場合、旧主体のリモートセッション、未完了要求、WebSocket 状態、モデルカタログ、キャッシュ、遅延イベントを無効化してから新しい主体を有効にする。
  • リモート sandbox ポリシーはリモートサーバーが実施する。ローカルの保護ディレクトリ判定でリモートホストを保護できるとは扱わない。
  • キャッシュ境界、承認の意味、継承/永続/次ターン設定に関する既存 ADR を維持する。変更が必要な場合は実装前に記録する。
  • Bearer トークン本文を設定、Remote UI、会話、ログ、診断、テレメトリ、クラッシュテキストへ保存しない。

Phase 1 — プロトコル契約と転送基盤

トラッキング: #150

契約・スキーマ基準

  • CLI 0.159.1 正式版を対象契約に固定する。CLI 0.155.1 正式版は回帰比較元として保持し、ローカル alpha のスキーマをどちらの正式契約としても扱わない。
  • 0.155.1 と 0.159.1 のそれぞれで標準スキーマと実験的スキーマを別々に生成し、構造差分を取得する。
  • CLI バージョンと生成オプションをスキーマキャッシュのメタデータに保存する。どちらかが異なる場合は、既存ファイルを有効なキャッシュとして扱わず再生成する。
  • 生成したスキーマは Git に含めない。
  • 使用する全メソッド、必須フィールド、列挙値、null 許容フィールド、未知 item、追加フィールド、不正 payload に加え、確認した 0.155.1→0.159.1 の全差分を契約テストへ追加する。

初期化と機能判定

  • サーバーのプラットフォーム種別/OS などの初期化メタデータを保持する。
  • initialize が汎用的なサーバー capability 一覧を返すとは仮定しない。
  • クライアント capability は end-to-end で実装済みのものだけ宣言する。
  • 宣言 capability、既知の契約、読み取り結果、-32601 を組み合わせて対応状況を判定する。
  • 利用可否を確認するために変更を生じるメソッドを呼ばない。

要求振り分けとライフサイクル順序

  • サーバー要求をメソッド名の完全一致と期待する payload 形式で振り分ける。
  • 未対応要求にはプロトコル上適切なエラーまたは仕様上の拒否を返す。未知の要求を汎用承認や既存許可へ流さない。
  • 接続世代、thread ID、turn ID、item ID、server-request ID ごとに状態を追跡する。
  • turn/start 応答と turn/completed/turn/started 通知の前後逆転を吸収する。
  • 接続終了時に、未完了のクライアント要求とサーバー要求を決定的にキャンセルまたは終了させる。
  • 古い接続世代から遅れて届く応答、通知、解決イベントをすべて無視する。

Issue #150 実装計画(2026-09-22 承認)

  • CLI 0.155.1 正式版を回帰元、0.159.1 正式版を対象として、Windows x64 リリース資産の digest と standard/experimental 生成面を追跡対象の契約 manifest に固定する。
  • CLI バージョン、生成面、generator 引数、metadata 形式、sentinel がすべて一致するときだけ schemas/<version>/<surface> を cache hit とする。一時 sibling へ生成後に原子的に置換し、生成スキーマと比較レポートは Git 管理外に保つ。
  • CI では固定した公式リリース資産2版を取得して SHA-256 を検証し、4組のスキーマを生成する。method、必須 member、型/null 許容、enum、additionalProperties を正規化比較する。0.159.1 の期待差分は、standard 面の thread attachment method/notification と null 許容 feedback prompt hash、experimental 面の userVerification/cancel と memory/status とする。
  • codexHome、platform family、platform OS、user agent を Worker 内だけの初期化 metadata として保持する。クライアント capability は実装済みの experimentalApi だけを宣言し、Remote UI 状態や Worker 契約 v16 は変更しない。
  • 推測による server-request 判定を完全一致 method dispatch と method ごとの shape 検証へ置き換える。未知 method は -32601、既知 method の不正 request は -32602 とする。未知 notification は transcript や承認状態へ投影せず、安全に記録して無視する。
  • outbound call、callback、未完了 approval/input、未対応 method 情報、turn 状態を接続世代 context に束縛する。接続置換/終了時に旧 handler と未完了処理を終了し、旧世代結果が現状態を変更する前に破棄する。
  • turn lifecycle を接続世代、thread ID、turn ID で縮約し、完了通知先行、遅延 start、重複完了、別 thread event が現在 turn を誤って復活/解除しないようにする。
  • cache 無効化と構造差分、使用する全 wire shape、未知/不正 payload、接続終了 cleanup、旧世代 event、代表的な CLI 0.159.1 stdio 通信を検証する。focused Core test、Protocol/Worker の警告ゼロ Release build、Core 全体、git diff --check を必須とする。

Phase 2 — 安全なリモート接続

トラッキング: #151

転送・プロファイルモデル

  • ローカル Worker 構成を維持し、Worker 内で stdio または WebSocket を選択する。
  • JSON-RPC 振り分け、メッセージ上限、キャンセル、未完了要求の終了、シャットダウン処理を転送方式間で共通化する。
  • プロファイルに表示名、接続先、トークンファイルのパス、ローカルルート、サーバールート、有効状態、選択中プロファイルを保存する。
  • トークン本文は接続時に Worker 内だけで読み取る。

接続先・所有権ポリシー

  • リモート接続先は wss を受け入れ、平文 ws は loopback だけ受け入れる。
  • WebSocket ハンドシェイク時に Bearer 認証を付与し、認証情報をログへ出力しない。
  • 証明書検証を無効化する設定は提供しない。
  • ローカルプロファイルは子プロセスの再起動を所有する。リモートプロファイルは接続だけを閉じ、操作名を「再接続」とする。
  • connect、reconnect、close を直列化し、1つの接続世代だけを有効にする。

診断・再試行

  • health endpoint は診断だけに利用する。health 成功を JSON-RPC や個別機能の利用可否とは扱わない。
  • ローカルプロセス状態とリモート接続状態を区別する。
  • 過負荷(-32001)後の指数バックオフと jitter は、明示的に冪等/読み取り専用の RPC にだけ上限付きで適用する。
  • 変更操作は自動再試行しない。

Phase 3 — パス対応付けと状態分離

トラッキング: #152

パス領域と対応付け

  • ローカルパスとサーバーパスを異なる型で表現する。
  • 正規化したルートをパス要素単位で対応付ける。C:\repo が C:\repo2 に一致してはならない。
  • Windows/POSIX の区切り文字、大文字小文字、ルート同値性、./..、長いパス、Unicode、ドライブ/共有、symlink/junction の挙動を定義する。
  • 作業ディレクトリ、IDE コンテキスト、添付、localImage、変更ファイルリンク、ファイル成果物、ローカルで開く/表示する操作に同じ対応付けサービスを使用する。
  • 対応付けできない添付は送信前に拒否し、対処可能な理由を表示する。
  • サーバーパスをローカルファイルとして直接開かない。

サーバー所有識別子と状態キー

  • スキルパスはサーバーが提供した識別情報として保持する。Visual Studio ホスト上に存在することを要求しない。
  • スキルキャッシュ、モデルカタログ、使用量、承認許可/監査、選択中会話、下書き、添付、履歴、WebSocket/セッション状態を接続先、アカウント、認証主体、作業ルートごとに分離する。
  • 接続先、アカウント、認証主体、ルートが変わった場合、選択中状態を決定的に切り替えるかクリアする。
  • 有効な接続世代と送信結果を、取得時の認証主体に結び付ける。アカウント切替、logout、所有主体変更時は、旧リモートセッションを閉じるか無効化し、未完了応答、WebSocket キャッシュ、モデルカタログ、通知を破棄する。
  • リモート sandbox の実施をリモートサーバーの責務として扱う。

範囲の境界とアカウント変更(2026-10-04 改定)

  • 変更ファイルリンク、ファイル成果物、画像プレビュー、開く/表示する操作は Phase 6(Issue #155)、保存済み添付、復元履歴、下書きは Phase 4(Issue #153)が提供する。いずれも Phase 3 のマッパー、境界、所有者パーティションを使用する。
  • 現在の所有者が開始したログアウトまたはサインインでは、旧所有者を無効化してから再送なしで新しい所有者へ自動接続する。それ以外のアカウント通知ではアカウントを再読み込みし、アカウント指紋が変わった場合だけ所有者を無効化して明示的な再接続とする。
  • 詳細なフォローアップ計画: パス対応付けと所有者状態の分離 — Issue #152。

Phase 4 — 再接続と履歴復旧

追跡: #153

詳細設計: English / 日本語。Worker 契約 v19 で実装済みです。Experimental Instance の視覚検証は未完了で、完了条件として維持します。

接続回復と隔離した下書き

  • Extension が単一の復旧管理を所有し、Worker 終了をまたいで1つの回復処理を行います。切断・終了した Bridge は、RPC proxy が non-null の場合も破棄して再作成します。各 Worker の接続試行には既存の遷移ゲートを使い、通知 callback は切断をキューに入れて戻り、回復を await しません。
  • 自動回復は一時的な Worker/子プロセス終了、通信断、応答停止、予期しないサーバー閉鎖だけを対象とします。認証、TLS/証明書、profile/設定/ルート、既知の所有者変更、キャンセルで自動試行を終了します。#152 の所有者自身による sign-in/sign-out 後の接続処理は別に維持します。Remote は socket を再接続し、外部サーバーは外部管理のままとします。
  • 試行は最大5回とし、各試行前の待機を順に0・1・2・4・8秒、0秒以外は ±20% の jitter とします。1試行45秒、全体5分を上限とし、手動操作との競合を直列化します。上限後は安定した手動再接続操作を示します。Remote の各試行で token file を再読込しますが、内容の更新だけでは回復を開始しません。
  • Reconnecting、復元確認待ち、Synchronizing history、履歴閲覧のみ、手動再接続待ちを区別します。有効な所有者状態を消去する前に、旧下書きの本文、添付参照、skill、次ターンの model/reasoning/speed/personality 設定を Extension のメモリに隔離します。試行中に上書きせず、VS 画面の寿命の間だけ保持します。
  • 新接続を initialize し、現在の所有者の thread 一覧を再取得します。接続先の確認と現在の所有者の会話選択の後、明示的な復元/破棄を提供します。復元は composer へのコピーだけとし、送信は別操作です。添付の対応付け・物理境界と model/skill/設定の catalog を再検証します。承認、cache、資格情報、保留 server request、秘密の proof は新所有者に移しません。ディスク保存は追加しません。

読み取り専用の履歴と添付の統合

  • thread/read は includeTurns=false、thread/turns/list は sortDirection=desc・itemsView=summary で最新50 turns、thread/items/list は sortDirection=desc で最新100 items を取得します。過去ページと turn 内の詳細は明示操作で取得し、返された文字列 cursor を使います。0.159.1 の構造化 exclusive item anchor は turnId と既知の item 境界を必要とし、0.155.1 の回帰経路は文字列を使います。
  • ページと保留通知は所有者、接続世代、thread/turn/item ID で統合します。完了 item を delta より優先し、重複や遅延 delta で表示を戻しません。表示は最大1,000 items・本文16 MiB の移動窓とし、通知は最大1,024件・8 MiB とします。超過時は同期失敗を明示し、読み取り専用の再取得操作を提供します。
  • 閲覧と再参加を分け、明示操作だけが thread/resume を excludeTurns=true で呼びます。稼働中の会話は「使用中の可能性」とし、他クライアントの所有と断定しません。resume が失敗しても取得済み履歴と隔離下書きを保持し、安全に表示できる理由と明示操作を示します。
  • thread/attachment/list は limit=50 で nextCursor が null になるまで取得します。1会話最大100件、1ページ最大100件、1件の serialized payload 最大64 KiB、attachmentType と identityKey は各256 UTF-8 bytes を検証します。#153 は payload の検証と上限付きの基本 metadata、#155 は詳細な解釈、preview、追加/削除、ファイル操作を担当します。未知・不正な形式は理由を示して操作を無効にします。protocol に共通 MIME field はありません。
  • 添付は (threadId, attachmentType, identityKey) と attachment ID で統合します。作成通知に payload はなく、上限付きの一覧再取得を行います。削除 ID の tombstone で古いページによる復活を防ぎ、同じ identity の新 ID は再作成として扱います。明示的な非一時 fork 後にも再取得し、旧所有者・旧世代の通知は拒否します。
  • v19 の実装時に4つの read method と添付通知を契約 manifest に追加します。read method を個別に確認して overload allowlist に加え、既存の3回再試行/合計4送信を接続回復とは分離します。resume と変更操作を overload retry の対象にしません。

結果不明の操作と検証

  • dispatch 境界で変更操作をローカルに記録します。NotSent は dispatch が始まっていない証明を必要とし、送信開始の可能性がある後の応答消失は OutcomeUnknown とします。履歴にないことや本文・時刻の一致では結果を確定しません。確定応答は記録した結果を確定でき、切断前に相関付けた server item ID は受理だけを示し、すべての副作用の完了は証明しません。
  • メッセージ、承認、MCP、shell、ファイル変更、添付変更を自動再送しません。不確定な内容を確認可能に保ち、コピー/編集/再検証の後、新しい送信を別の明示操作とします。ローカル操作 ID を wire の idempotency field にせず、期限切れ request ID と秘密の proof を再利用しません。
  • 回復対象の除外、5回失敗、手動操作との競合、旧世代、下書きの復元/破棄・再検証、ページと通知の競合、完了 item 優先、履歴上限、添付の削除/再作成/fork/上限、自動再送ゼロを検証します。Core/UI テスト、警告ゼロの Debug/Release ビルド、対象/回帰契約、VSIX 検査を行います。Experimental Instance のスクリーンショットで Light/Dark/High Contrast、狭い幅、キーボード/focus、回復・履歴・下書きを判定します。Worker 契約 v19 の実装と自動/package 検証結果は記録済みです。Experimental Instance の視覚検証は未完了です。

Phase 5 — 質問・権限範囲・MCP 対話

トラッキング: #154

子 issue: Issue #165: 契約と要求ライフサイクル、Issue #166: 質問カードと権限範囲、Issue #167: MCP elicitation と認証回復、Issue #168: Gateway OAuth と統合検証。

Worker 契約 v19 から開始し、merge 時点で次に利用可能な契約 version を割り当てます(途中変更がなければ v20)。CLI/SDK/runtime は既存の基準を維持し、CLI 0.159.1 を対象、0.155.1 を回帰比較用とします。

契約と要求ライフサイクル

  • 非同期質問、権限要求、コマンド承認、MCP elicitation、Gateway OAuth、未対応の本人確認要求をそれぞれ別の要求/応答型で扱います。
  • 接続世代と元の JSON-RPC request ID をキーとする保留要求レジストリを使用します。turn ID のない MCP 要求も管理し、すべての応答に既存の owner 検証を適用します。
  • 回答を検証してから完了権を原子的に取得します。回答、キャンセル、timeout、切断、serverRequest/resolved の競合でも応答は最大1回とします。resolved 要求や破棄済み世代には応答せず、配送結果不明の応答を再送しません。

質問と権限

  • ターンが継続中でも操作でき、通常 composer を塞がない独立カードを表示します。blocking/non-blocking 質問、自由入力、「その他」を扱います。選択・focus・既定値は表示状態であり、明示 Submit だけが回答です。
  • secret マーカー付き質問は UI 投影を作る前に Worker で検出します。安全な専用入力経路がないため理由を示して拒否し、秘密内容を通常 UI、会話、ログ、設定、診断、例外へ渡しません。
  • 要求されたネットワーク/ファイル権限のうち選択部分だけを返します。既定は turn scope、session scope は明示操作で選択します。サーバー要求にない権限は拒否します。
  • コマンド承認の全選択肢と追加権限を表示し、ルール変更の選択肢も独立したサーバー選択肢として保持します。破壊的操作には既存の承認ポリシーを適用します。

MCP elicitation と認証回復

  • 正確な mcpServer/elicitation/request を処理します。対応する form field(string、number、integer、boolean、単一/複数選択)について required、型、長さ、範囲、形式、選択数を UI と Worker の両方で検証します。
  • openai/form など未対応の拡張 schema は理由付きで拒否し、拡張フォーム capability を宣言しません。
  • 認証 URL は Worker で検証・保持し、明示的なユーザー操作だけでブラウザーを開きます。ブラウザーを開いた事実だけでは認証成功とみなしません。
  • mcpServer/oauth/login、mcpServer/oauthLogin/completed、起動状態通知を連携します。期限切れ、失効、reauthenticationRequired では再認証を案内し、古い elicitation を終了します。MCP に取消 RPC がないため、UI 取消をサーバー認証の取消として扱いません。
  • 再認証後は新しい明示的なツール呼び出しを要求し、失敗したツール呼び出しを自動再送しません。

Gateway OAuth とネイティブ本人確認

  • ローカル stdio だけで explicitGatewayOauth を宣言します。初期化後、認証を要する RPC より先に account/gatewayOAuth/read を成功させます。このゲートを接続ごとに行い、その後に login/cancel/changed 通知と明示的なブラウザー操作を扱います。
  • Gateway OAuth 通知を有効な接続と owner に結び付けます。login 待ちで他の RPC の処理を塞ぎません。未対応または初回 read 失敗時は認証付き RPC を止め、自動ブラウザー認証へ切り替えません。
  • Remote 接続では状態とサインイン案内だけを提供し、capability の宣言や Gateway OAuth の login/cancel 変更要求を行いません。
  • 固定版 CLI 0.159.1 の本人確認は macOS のみ対応し、この拡張 client は上流の適格対象に含まれません。Windows と拡張 client の上流対応までは成功経路を延期します。今回 capability を宣言・転送せず、要求を理由付きで拒否します。challenge、proof、credential を UI、会話、ログ、設定、診断、例外へ出しません。

添付の担当範囲

  • Phase 5 は保存済み添付の契約拡張や UI 動作を追加しません。上限付き metadata の復旧は Phase 4/Issue #153、添付の操作と表示は Phase 6/Issue #155 が担当します。

Phase 6 — 日常利用の App Server 機能

トラッキング: #155。詳細計画: App Server 日常機能(2026-10-08承認)。

既存の catalog reasoning/service tier/default、構造化 turn plan、#152 の mapping/所有者、#153 の保存添付復元、#154 の MCP 認証/対話を再利用する。

  • 上限付き item/plan/delta(EXPERIMENTAL 記述のため任意)と完了 plan による置換を追加し、thread/config/model/MCP 実行通知を操作可能な対話と区別する。

  • modality と access 情報をカタログに追加し、継承/永続/次ターン指定を保持したまま turn/start 前に実効モデルの入力を検証する。

  • /shell [--timeout-ms N] -- <command> は明示入力、正確な対象/command/cwd 確認、ローカル policy 評価の後だけ送信する。0.159.1 の thread/shellCommand は常に sandbox 外で、即時受付は完了ではない。省略は1時間、0 は即時 timeout、負数/overflow は拒否。thread ごとの未確定送信は1件で、確定結果か世代終了でのみ解除する。

  • 型付き MCP/image/file 出力、server/local 切り詰めの区別、上限付き PNG/JPEG preview、変更ファイルリンクと操作直前の物理境界検証付き Open/Reveal を追加する。

  • 既存の保存添付 list/merge を client 所有の relaycodex.file.v1 registry と明示 add/remove で拡張する。MIME は client payload 固有で protocol field ではない。未知項目は read-only 表示し、不明な変更を再送しない。

  • ローカル Windows 限定の明示 sandbox setup(mode、検証済みソリューションルートの cwd または null、start/completion)を不定進捗と正確な失敗/不明状態で表示する。進捗率や status 読取 API はない。

  • 0.159.1 追加フィールドは詳細計画に従う。metadata から plugin 編集、資格付与、native 確認、埋め込み web 実行を許可しない。rollout/compress は対象外。

  • PR #170 で Phase 6 の実装と自動検証が完了し、Issue #155 は close 済み。未完了の Experimental Instance 表示/アクセシビリティ受入は完了扱いにせず、Issue #156 の Local-required として残す。

Phase 7 — 統合検証とリリース準備

トラッキング:Issue #156。詳細条件は承認済み統合リリース検証計画に定める。

基準は main の b44e856、Worker contract v21、CLI 0.159.1、回帰 fixture 0.155.1。PR #170 の結果は過去の証跡であり、後続 release candidate の結果には流用しない。

シナリオ区分と証跡

  • Local-required: 固定 schema 比較、Fake App Server とローカル suite、transport/TLS/token rotation 模擬、path 境界、VSIX integrity、Windows Experimental Instance、同一マシン上の2 instance 分離。必須項目すべての合格を必要とする。
  • External: 認証を伴う固定 CLI 通信、実 MCP OAuth の期限切れ/再認証、実 remote TLS/証明書/token rotation。公開 CI 外で手動実行する。各項目は合格、またはリスク、代替証拠、承認者、日付、承認元を記録した明示承認済み blocked とする。
  • シナリオごとに passed、failed、blocked、not-run、flaky を記録する。failed/flaky/not-run があれば準備完了としない。必須 skip は blocked とし、Local-required の blocked は未完了。環境制約だけで External を免除しない。
  • 初回結果を保存し、失敗した test case だけを1回再試行する。再試行合格は flaky として gate を失敗させる。data-driven case を分離できない場合や test host が異常終了した場合、suite 全体を再実行しない。
  • 実際の test identity で専用一時領域への symlink/junction 作成を試す。skip は test 名と実際の理由を記録し、PR #170 の6件は TRX なしに原因を推定しない。
  • 秘密除去済み TRX、diagnostic、schema report、hash、結果 manifest を if: always() で必ず収集する。認証済み生通信は公開 CI/成果物へ含めない。

UI と Windows 受入

SDK 管理の F5/Experimental Instance 手順と重複 identity guard を使用する。Light/Dark/High Contrast、狭幅、接続/復旧/履歴/下書き、質問/権限/MCP、添付/成果物、shell 確認、Windows setup、keyboard/focus 順、accessible name、Narrator/Accessibility Insights の通知、長い履歴、同一マシン上の2 instance を確認する。

スクリーンショットには scenario ID、環境、期待結果、合否を付ける。keyboard/読み上げには手順と観測記録も必要とする。オフスクリーン WPF 描画は補助証跡。全 solution、WPF UI、固定 Windows CLI schema 生成、VSIX、Experimental Instance の受入は Windows で実施し、Core/Worker net8.0 の他 OS 実行を Windows 証跡の代替にしない。

ネイティブ本人確認の境界

capability 未宣言、payload 投影前の拒否、challenge/proof の非露出、遅延 resolve/cancel event の無視、principal 変更時の未完了状態破棄を検証する。enroll/verify/cancel/delete の成功フローは未対応であり受入条件にしない。新規 ADR は不要。

後続実装の範囲

本 Phase は証跡と準備完了基準を定める。PowerShell 7 統合 script、CI/Release workflow、不足 test、External 実行、Experimental Instance 受入は Issue #156 の承認済み計画に基づく後続実装とする。

完了条件

  • 正確な最終 candidate commit で Local-required をすべて合格させる。failed/flaky/not-run を残さず、必須 skip/blocked は未完了とする。
  • すべての External が合格、または承認者・日付・承認元を記録した証跡付きの明示承認済み blocked である。
  • 結果 manifest と秘密除去済み証跡を記録し、PR #170 の件数/hash は現 candidate の結果と区別する。
  • Experimental Instance のテーマ、狭幅、workflow、keyboard、focus、accessibility、長い履歴、同一マシン上の instance 分離が合格し、証跡がある。
  • Issue #155 は close 済みだが、未完了の Phase 6 画面/対話受入は #156 に Local-required として引き継ぐ。
  • ネイティブ本人確認の拒否と秘密情報境界を検証する。成功フローは要求しない。

後続計画とする機能

次の機能は有用だが、追加の製品設計、ライフサイクル設計、信頼境界設計が必要なため別計画とする。

機能 扱い
Windows 共有 daemon、自動 worktree 作成・管理 外部サーバー接続が安定した後の後続。サーバー lifecycle と Git 操作は分離する
会話の名前変更、ピン、アーカイブ 履歴復旧の完成後に追加する
Voice/Realtime、dynamic tools UI、転送、権限を別途設計する
ExternalMessage 直接のユーザー入力との権限差を先に定義する
プラグイン管理、他エージェント設定の取り込み 正本と変更確認を別計画で定義する
Attestation attestation provider と trust model が定まるまで opt-in のままとする

参照

⚠️ **GitHub.com Fallback** ⚠️