VS Code 1.145: リモートエージェントと MCP コントロール

Microsoft が 2026 年 11 月 4 日にリリースした Visual Studio Code 1.145 は、リモートエージェントによる作業をローカルエディターの体験にさらに近づけます。このリリースでは、リモートアプリケーションのプレビュー、リモートキャンバス、mixed agent harness、cron ベースのローカル自動化、チャット表示コントロール、添付ファイルの変更、MCP ガバナンスの更新、ファイル除外の例外、拡張 API の作業、Local harness の削除が追加されます。

CTO とエンジニアリングリーダーにとって、シグナルは明確です。エージェントファーストの開発は、チャットを超えてリモート実行、定期的な自動化、インタラクティブなインターフェース、ポリシー制御されたツールへと拡大しています。ワークフローのカバレッジが広がる機会がある一方、Preview フラグ、サンドボックスの依存関係、MCP の優先順位、および削除された Local harness ツールは、展開前に慎重な検証を必要とします。

1. VS Code 1.145 の安定版ビルド出荷

概要

Microsoft はリリースページで、Windows、macOS、Linux 向けの Visual Studio Code 1.145.0 のダウンロードを提供しています。利用可能な形式には、x64 および Arm64 の Windows ビルド、Universal、Intel、Apple Silicon の macOS ビルド、一般的な Linux パッケージが含まれます。

これは Insiders 限定のパッケージではなく、安定版リリースです。

重要性

プラットフォームチームは、既存のエディター配布プロセスを使用して、制御された展開を開始できます。Preview および Experimental のラベルは個々の機能に引き続き適用されるため、安定版エディターをインストールしても、含まれるすべての機能が本番環境対応になるわけではありません。

これが重要な理由： エディターのアップグレード判断と機能の有効化を分離してください。パイロットリングを通じて 1.145.0 を展開し、その後、ゲート付きのエージェント機能およびガバナンス機能を個別に評価します。

2. リモートエージェントのブラウジングとキャンバス

概要

Microsoft によると、workbench.browser.enableRemoteProxy を有効にすると、Agents ウィンドウの統合ブラウザーはリモートエージェントホストを介してページを読み込めるようになりました。エージェントがリモートマシンで開発サーバーを起動した場合、開発者は Agents ウィンドウ内でそのアプリケーションを開き、結果を確認し、セッションを離れずにフィードバックを提供できます。

リモートキャンバスは同じ接続を基盤としています。chat.canvases.enabled と workbench.browser.enableRemoteProxy の両方を有効にすると、リモートエージェントホストによってホストされるキャンバスを VS Code に表示できます。

キャンバスは、Add to Sidebar アクションを使用して左サイドバーにピン留めすることもできます。Microsoft はリモートブラウジングとリモートキャンバスを Preview、サイドバーへのピン留めを Experimental と位置付けています。

重要性

リモートプレビューにより、エージェントが別のホスト上でコードを変更する一方で、検証は別途構成されたブラウザーで行われる際のコンテキスト切り替えを削減できます。このルーティング変更も重要です。ブラウザートラフィックは開発者のワークステーションではなく、リモートホストを経由して発信される可能性があります。

規制対象の環境では、このネットワーク上の違いは譲れません。検証計画では、どのホストが宛先を解決するか、どのネットワークリソースに到達可能になるか、リモートアプリケーションのコンテンツを Agents ウィンドウ内に表示することが適切かを確認する必要があります。

アクション： 広く有効化する前に、代表的な SSH、WSL、Dev Container のワークフローで workbench.browser.enableRemoteProxy をテストしてください。キャンバスはエージェント提供のインタラクティブなインターフェースを導入するため、chat.canvases.enabled は別個の承認対象として扱います。

3. Mixed Harness と Copilot への移行

概要

ネストされたセッションは以前、親セッションの harness を継承していました。VS Code 1.145 では、chat.agentHost.multipleChatProviders.enabled を有効にすると、異なる harness を使用するチャットを 1 つの親セッション内に配置できるようになります。

Microsoft は、Copilot チャットで作成したプランのレビューを Claude に依頼したり、同じタスクを Codex に割り当てて並列比較の結果を得たりする例を挙げています。各チャットは、移動またはフォークされた場合も、自身のモデル、エージェント、アクセス許可レベル、履歴、選択された harness を維持します。

harness ピッカーでは Copilot セッションが識別されるようになり、Copilot harness セッションは Agent Host を通じてバックグラウンドで継続できます。Microsoft は、カスタマイズの互換性、セッション継続性、組織的なロールアウト、および検証を扱う、Local-to-Copilot harness 移行ガイドも追加しました。

重要性

Mixed harness により、モデル比較が、分断されたセッションの集合ではなく、単一の作業コンテキストの一部になります。これは単なる UI の利便性ではありません。プロバイダーの選択、承認範囲、モデルの振る舞いを、同じ作業単位の中に配置します。

組織は、chat.agentHost.multipleChatProviders.enabled を有効にする前に、並列利用するプロバイダーが既存の AI 利用ポリシーに適合するかを判断する必要があります。チャットは自身の harness に関連付けられたアクセス許可を維持するため、レビュー担当者は兄弟チャットが同一のコントロールを共有していると想定してはなりません。

これが重要な理由： harness の移行は運用モデルの判断になりつつあります。Local harness のカスタマイズを棚卸しし、Copilot harness の互換性を検証し、組織ポリシーで許可される代替 harness を確認してください。

4. Cron スケジュールとローカルエージェント自動化

概要

ローカル自動化では、組み込みのスケジュールプリセットが十分に精密でない場合に、カスタムの 5 フィールド cron 式を使用できるようになりました。Microsoft によると、スケジュール設定ダイアログは式を検証し、生成されるスケジュールを説明します。

この機能はローカル自動化にのみ適用されます。このリリースでは、クラウド自動化に cron スケジュールは使用できません。

VS Code 1.145 では、ローカル自動化で選択したワークスペースのカスタムエージェントも利用できます。無効化された自動化は折りたたまれたセクションに移動するため、有効なスケジュールと実行履歴が目立つ状態に保たれます。

重要性

Cron により、自動化はプリセット主導の利便機能から、より柔軟な定期実行レイヤーへと拡張されます。この柔軟性は、無人のエージェントアクティビティ、ワークスペースの状態、資格情報、マシンの可用性に関する運用上の疑問も生み出します。

これはクラウドスケジューラーではありません。ローカル Agent Host に紐付く定期実行です。

アクション： cron ベースの自動化ごとに、所有者、実行時間枠、レビュー手順を必須にしてください。エディターで式を検証し、選択したワークスペースエージェントを文書化し、タスクの実行予定時にホストが利用可能であることを確認します。

5. Working Set と必須サンドボックス

概要

Microsoft によると、Copilot harness セッション向け Experimental working set は、WSL、Dev Container、SSH ワークスペースのファイルを正しいホストで開くようになりました。並列するツール呼び出しが同じファイルを編集する場合、working set はそれらの変更を追跡し、編集完了後もインラインレビューコントロールを利用可能な状態に保ちます。

このリリースでは、組織がエージェントのサンドボックス化を必須としているにもかかわらず、マシンでそれを実行できない場合に表示される警告も改善されています。このバナーは、依存関係の不足など、ターミナルコマンドがブロックされる理由を特定し、ユーザーをトラブルシューティングへ導きます。

アカウントおよび組織でサポートされている場合、ローカルエージェントツールを実行できないときに、Microsoft は Experimental cloud sessions を検討するよう提案しています。

重要性

エディターウィンドウがローカルとリモートのリソースにまたがる場合、正しいホストの選択は不可欠です。この境界の誤った側でファイルを開くと、レビューが混乱し、編集の発生元が不明瞭になり、誤った環境に修復を向ける可能性があります。

サンドボックスの警告も同様に重要です。ポリシーで必須とされるサンドボックスはフェイルクローズします。互換性のあるサンドボックスがない場合、必要な分離なしにサイレント実行されるのではなく、ターミナルコマンドがブロックされます。

アクション： エージェント受け入れテストに WSL、Dev Container、SSH の working set シナリオを追加してください。管理対象サンドボックスでは、必要な依存関係を文書化し、ブロッキングバナーを受け取ったユーザー向けのエスカレーションパスを確立します。

6. チャットの詳細度、パフォーマンス、添付ファイル

概要

Experimental の chat.persistentProgressVerbosity 設定には、次の 3 つの表示モードが導入されます。

• Conversation: 推論とツール呼び出しが、応答テキストの間に折りたたみセクションとして表示されます。
• Verbose: ツール呼び出しは展開されたままとなり、ツールグループ内のスクロール制限はありません。
• Compact: ツール呼び出しは実行中に表示され、その後サマリー行に折りたたまれます。これがデフォルトです。

モードの変更は、チャットコンテキストやエージェントの動作ではなく、表示に影響します。ユーザーは別のセッションを開始せずにモードを切り替えられます。別個の chat.progressBorder.enabled 設定は、永続的な進捗インジケーターをアニメーション付きの入力枠線に置き換えます。

Microsoft はまた、VS Code が既存の推論タイトルを再利用し、表示されたときに復元済みのターミナル出力をレンダリングし、繰り返される進捗更新とレイアウト計測を減らすため、長い Copilot harness チャットがよりスムーズに再開されるようになるとしています。

Experimental の chat.inlineAttachments.enabled 設定では、添付ピルがカーソル位置に配置されます。これは Insiders ではデフォルトで有効、Stable ではデフォルトで無効です。

重要性

詳細度は、機能コントロールではなく可観測性コントロールです。Verbose モードはトラブルシューティングとレビューを支援できる一方、Conversation モードは日常的な作業の視覚的負荷を軽減します。

遅延レンダリングにより長いセッションを再開しやすくなるはずですが、セッションガバナンスやレビューの重要性は低下しません。一方、インライン添付は、指示と参照コンテキストの関係を維持するため、複雑なプロンプトの曖昧さを減らせます。

アクション： シナリオごとに推奨の表示モードを標準化してください。日常業務には Compact または Conversation を使用し、ツールの動作、アクセス許可、予期しない結果をレビューする場合には Verbose を使用します。

7. 外部添付ファイルとセッションアクセス

概要

ユーザーは Add Context、続いて Files を選択することで、アクティブなワークスペース外のファイルを含む 1 つ以上のファイルを、標準システムダイアログから添付できるようになりました。これは、ワークスペースを開かずに新しいチャットを開始した場合にも機能します。

Microsoft によると、cloud-session のファイル選択画面には画像のみが一覧表示されます。サンドボックス化された Copilot harness セッションでは、添付パスはそのセッションの残りの期間は読み取り可能になりますが、書き込みはできず、アクセスは設定に保存されません。

Manual permissions では、明示的に添付されたファイルを読み取る前に、エージェントが確認を求めなくなります。エンタープライズ管理の設定で読み取り可能なパスが定義されている場合も、添付ファイルがその管理リストに自動追加されることはありません。

重要性

ファイルダイアログにより外部コンテキストの追加は容易になりますが、デスクトップ上のファイルとエージェントセッションの間の摩擦も下がります。重要な境界は明示的な添付です。選択されたパスは、ワークスペース外にある場合でも、そのセッション中は読み取り可能になります。

これはセッションスコープのアクセスであり、永続的なポリシー変更ではありません。

アクション： ユーザーに、添付を情報開示の判断として扱うよう教育してください。管理対象環境では、外部添付がサンドボックス、Manual permissions、cloud-session の画像制限、エンタープライズの読み取り可能パスコントロールとどのように相互作用するかをテストする必要があります。

8. MCP アプリとエンタープライズ許可リストの優先順位

概要

MCP アプリは、言語モデルが次のリクエストで呼び出せるツールを登録できるようになりました。Microsoft は、モデルがインタラクティブなインターフェイスを通じてシェーダーを反復調整できる MCP アプリの例として、ShaderToy サーバーを挙げています。

VS Code によって開始される MCP サーバーでは、エンタープライズ管理の allowedMcpServers リストが、レジストリのみのアクセスより優先されるようになりました。管理対象リストに一致するサーバーは、レジストリで公開されていなくても実行できます。一方、リストに存在しないレジストリ サーバーはブロックされます。

Microsoft は次の境界条件を示しています。

• 空のリスト: [] はすべての MCP サーバーをブロックします。
• リストがない場合: 従来どおり、レジストリのみの制限が適用されます。
• ユーザーおよびワークスペース ポリシー: これらのスコープからエンタープライズ リストにサーバーを追加することはできません。
• 拒否: deniedMcpServers および MCP の無効化は引き続き優先されます。
• スコープ: この変更は VS Code によって開始されたサーバーに適用され、Agent Host によって管理されるサーバーには適用されません。
• 照合: Microsoft は、serverName よりも serverUrl および serverCommand ルールを推奨しています。

重要性

MCP アプリは、インタラクティブなインターフェイスと呼び出し可能なツールを組み合わせます。これにより、承認済みサーバーがモデルに公開できる機能が拡大するため、サーバーの承認は実質的にツールの承認にもなります。

許可リストの優先順位変更は、より即時性の高い管理上の問題です。レジストリのみのポリシーも有効な場合であっても、管理対象リストが VS Code 開始サーバーの信頼できる一覧になります。

対応: 1.145 を展開する前に allowedMcpServers を再評価してください。承認済みのすべての serverUrl と serverCommand が意図したものであることを確認し、古いエントリを削除して、空のリストが想定どおり全ブロックの状態を生成することをテストしてください。

9. ファイル除外、Mermaid、必須プラグイン

概要

files.exclude および search.exclude 設定で、! を先頭に付けた例外をサポートするようになりました。たとえば、ワークスペースでは node_modules を除外しつつ、!node_modules/@types は表示対象として維持できます。

files.exclude の例外は Explorer、Search、Quick Open に影響します。search.exclude の例外は Search と Quick Open のみに適用されます。Microsoft は、!**/node_modules/@types のような広範なパターンにより検索が遅くなる可能性があると警告しています。

Mermaid のレンダリングも 1.145 で変更されます。エッジが交差する場合、サブグラフのタイトルは移動し、既定の VS Code Mermaid テーマではサブグラフを塗りつぶすのではなく輪郭線で表示します。

管理対象の enabledPlugins 設定を通じて必須とされたエージェント プラグインでは、VS Code がアンインストール操作を無効にするようになりました。この制限は、提供されるプロンプト、スキル、エージェント、フック、MCP サーバーにも適用され、ホバーおよびキーボード フォーカスで説明を確認できます。

重要性

除外の例外は、大規模な生成物または依存関係ツリーを隠しながら、開発者が調査する必要のある特定部分を表示したままにするという、一般的なワークスペースの課題を解決します。パフォーマンスに関する警告は、チームが深さ全体に及ぶ例外よりも限定的なパターンを優先すべきことを意味します。

必須プラグインの動作は、組織の意図に沿うものになりました。ユーザーは、実行しても失敗するだけのアンインストール操作に遭遇しなくなります。

対応: 共有の files.exclude および search.exclude 構成に、広範な否定パターンが含まれていないか確認してください。管理対象プラグインについては、enabledPlugins エントリを検証し、必須の各カスタマイズをインストールしたままにする理由を文書化してください。

10. プル リクエストと正式版 Timeline API

概要

GitHub Pull Requests 拡張機能のバージョン 0.176.0 では、プル リクエスト概要のタイムラインが拡張されます。Microsoft は、ラベル、マイルストーン、タイトル、レビュー依頼、レビュー却下、ドラフト、レビュー可能状態、force-push、ブランチ復元、自動マージ、マージ キューのイベントを追加項目として挙げています。

プル リクエストの説明テンプレートでは、Start Working on Issue を通じてブランチが Issue に関連付けられている場合、${issueTitle}、${issueNumber}、${issueNumberLabel} を使用できるようになりました。スタック化されたプル リクエストのワークフローでは、スタック内のプル リクエストで自動マージが有効になっている場合に、それを無効にするようユーザーへ促すようにもなりました。

これとは別に、Microsoft は Timeline API を正式版として確定しました。Marketplace 拡張機能は、workspace.registerTimelineProvider を使用してファイルおよびフォルダーのプロバイダーを登録でき、workspace.registerWorkspaceTimelineProvider を使用してワークスペース全体のプロバイダーを登録できます。TimelineItem.resourceUri をエントリが表すリソース状態に設定すると、Compare Selected による比較が有効になります。

重要性

この拡張機能更新では、プル リクエストのライフサイクルがエディター内でより多く表示されるため、レビュー担当者がコード差分以外の状態変更を見逃す可能性が低下します。ブランチが追跡対象の Issue から作成される場合、テンプレート変数によって一貫性も向上できます。

正式版の Timeline API は、拡張機能作成者にドメイン固有の履歴のための安定した統合ポイントを提供します。これは監査、比較、変更説明のワークフローに有用ですが、拡張機能チームは最小対応 VS Code バージョンを意図的に設定する必要があります。

対応: テストリングで GitHub Pull Requests 拡張機能を 0.176.0 に更新し、新しい Issue 変数を使用できるテンプレートを確認してください。拡張機能の所有者は、Timeline プロバイダーで独自の履歴ビューを置き換えられるか評価すべきです。

11. Local harness ツールの削除

概要

Microsoft は Local harness セッションからいくつかのツールとコマンドを削除しました。

• 拡張機能のインストール: #installExtension は利用できなくなりました。代わりにエージェントが必要な拡張機能を .vscode/extensions.json に追加し、ユーザーが確認してインストールします。
• コマンド実行: #runCommand は利用できなくなりました。Developer: Chat Diagnostics などの必要なコマンドは、組み込みワークフローからユーザー自身で実行するよう求められます。
• ワークスペースの作成: #newWorkspace、その旧名称である #new、および /new コマンドは削除されました。
• プロジェクト セットアップ: Generate New Workspace リンクおよび専用のプロジェクト セットアップ スキルは削除されました。

Microsoft は、github.copilot.chat.newWorkspaceCreation.enabled、github.copilot.chat.newWorkspace.useContext7、github.copilot.chat.useProjectTemplates も削除しました。ノートブックの作成に変更はありません。

プロジェクトを作成するには、ユーザーが空のフォルダーを開き、エージェント セッションでプロジェクトを説明します。エージェントは標準ツールを使用してファイルを作成し、スキャフォールディング コマンドを実行し、タスクを構成します。

重要性

削除された識別子を参照するカスタム エージェントおよびプロンプト ファイルは、設計どおりに動作しなくなります。これは任意のクリーンアップではなく、移行作業です。

拡張機能に関する変更は、確認ポイントも回復します。エージェントはプロジェクトの拡張機能を直接インストールするのではなく、.vscode/extensions.json を通じて推奨するようになります。#runCommand の削除も同様に、コマンド呼び出しをユーザー側へ戻します。

対応: カスタム エージェント、プロンプト ファイル、ワークスペース テンプレート、内部ドキュメントで、#installExtension、#runCommand、#newWorkspace、#new、/new、project-setup-info-local、project-setup-info-context7 を検索してください。1.145 を標準化する前に、すべての参照を削除または置き換えてください。

12. 信頼性の修正とポリシーの永続性

概要

Microsoft は、エンタープライズに直接関係するポリシー関連の修正を 2 件示しています。

Issue #345207 は、ユーザーが Claude または Codex エージェントを選択した後に、組織がそのエージェントを無効化した場合に影響しました。New Chat、New Chat Editor、および新しいウィンドウで、入力欄のない読み取り専用チャットが開くことがありました。VS Code 1.145 では既定の harness にフォールバックし、未送信のプロンプトを引き継ぎます。後でポリシーにより許可されれば、以前の選択肢を再び利用できます。

Issue #344895 は、ネットワーク エラーまたはレート制限により GitHub Copilot ポリシーの更新に失敗した場合の、レジストリのみの MCP アクセスに影響しました。VS Code は現在、最後に認識されたレジストリ ポリシーを保持し、GitHub が適用されるレジストリはないと報告した場合にのみクリアします。

このリリースには、PR #336022 におけるターミナル自動応答のメモリ使用量、PR #342418 におけるタスク準備完了の競合状態、PR #344185 および #344764 におけるリモート ポート ルール処理、PR #344094 における Server-Sent Events のバイト オーダー マーク処理に対する修正も含まれます。

重要性

MCP の修正は、一時的な更新失敗により、次の更新成功時までレジストリ制限が解除される可能性があったフェイルオープンの期間を解消します。最後に認識されたポリシーを保持することは、適切なエンタープライズの姿勢です。

無効化されたエージェントのフォールバックも、管理者が harness の可用性を変更する際の展開リスクを低減します。ユーザーは、取り残された読み取り専用セッションではなく、動作する既定値を利用できます。

対応: ロールアウト テストには、ポリシー更新の失敗とエージェント無効化の遷移を含めてください。シミュレートした接続障害中もレジストリ制御が維持されること、および新しいチャットが組織で許可された既定の harness にフォールバックすることを確認してください。

13. Blobby Jump Game

概要

Microsoft は、VS Code のペットである Blobby を使った Experimental のプラットフォーム ジャンプゲームを追加しました。チャットで /vscode-pet を入力すると Blobby が表示され、Agents ウィンドウの新規セッション画面には Play Jump Game 操作が提供されます。

スペースバーでジャンプをチャージし、矢印キーで次のプラットフォームに向けて狙いを定めます。ゲームはデバイス上にハイスコアを保存します。

重要性

このゲームは、エンタープライズのワークフローに実質的な影響を与えません。任意機能であり、Experimental です。

管理環境では、ロールアウト計画ではなくリリース認識の対象です。チームは、リモート ルーティング、エージェント権限、自動化、添付ファイル、MCP ポリシーに検証作業を集中させるべきです。

まとめ

VS Code 1.145 は、Agents ウィンドウをリモート プレビュー、キャンバス、プロバイダー固有のチャット、定期的なローカル タスク、MCP 対応ツールのコントロール サーフェスへと拡張します。ここでエージェント ファーストは単なるトレンドではなく、エディターのワークフロー設計が向かう方向です。

1. まずリモート ルーティングをパイロット導入する。 代表的なホストおよびネットワーク境界に対して、workbench.browser.enableRemoteProxy と chat.canvases.enabled を検証します。
2. 定期実行を管理する。 5 フィールドの cron 自動化を、担当者とレビュー手順を明確にした無人ローカル ワークロードとして扱います。
3. MCP ポリシーを整理する。 allowedMcpServers、deniedMcpServers、レジストリ制限、および VS Code 開始サーバーと Agent Host 管理サーバーの違いを監査します。
4. Local harness のカスタマイズを移行する。 1.145 で削除されたツール、コマンド、スキル、設定への参照を削除します。
5. 障害状態をテストする。 広範な展開の前に、必須サンドボックスの動作、ポリシーの永続性、無効化された harness のフォールバック、添付ファイルへのアクセスを確認します。

Happy Coding!