VS Code 1.118の新機能｜codebase semantic indexが使えない原因・devcontainer-lock.json・Copilot設定の変更点

Visual Studio Code 1.118は2026年4月29日に公開された週次リリースで、翌4月30日には「VS CodeからGitHub Copilot CLIが動かない」不具合を直した1.118.1が出ています。この版の中心は、Copilotのcodebase semantic index（意味で検索するためのインデックス）がGitHub以外のリポジトリにも広がったことと、Dev Containerのロックファイル devcontainer-lock.json が既定で作られるようになったことです。この記事は1.118で何が変わり、その後の版で何が変わったかに絞っています。現在の最新バージョンと確認方法はVS Codeの最新バージョンの記事で扱っています。

まとめ

• 1.118は2026年4月29日公開。1.118.1（4月30日）はCopilot CLIの起動不具合だけを直した修正版。
• codebase semantic indexはGitHub・Azure DevOps以外のワークスペースにも対象が広がった。ただしGitHub以外のリポジトリ向け機能は、組織・Enterpriseではポリシーによる有効化が必要で、利用時には対象ファイルがGitHubへアップロードされる。
• node_modules・dist・out などのフォルダは、GitHub以外のリポジトリをGitHubへ送る経路でも常に除外される（1.142.0のソース）。アップロードしたインデックスは「Developer: Delete External Ingest Codebase Index」で消せる。
• github.copilot.chat.localIndex.enabled はsemantic indexの設定ではなく、チャット履歴を記録するChronicleの設定。
• devcontainer-lock.json が既定で作られるようになり、Featureの版とSHA-256チェックサムを固定する。CIでは --frozen-lockfile で差分を検出できる。
• Copilotを共著者としてコミットに自動追加する設定は、1.117ではall、1.118と1.118.1ではchatAndAgentが既定だった。1.119で既定値がoffに戻っている。

VS Code 1.118の変更点一覧とリリース日

1.118の公式リリースノートは6項目を目玉に挙げています。Copilot CLIのリモート操作、コードベース検索、スキル専用コンテキスト、チャット履歴の分析（Chronicle）、組織単位のアクセス制御、トークン効率化です。下の表では、この6項目に、Dev Containerなど目玉以外の変更を加えて、設定キーと1.118時点の状態をまとめました。

1.118.1のGitHub Releasesに書かれた修正内容は「Fixed GitHub Copilot CLI not working from VS Code.」の1行だけです。それ以外の変更はリリース説明に書かれていません。

codebase semantic indexの対象拡大と使えないときの原因

semantic indexは、コードを意味で検索するためのインデックスです。「認証はどこで処理している？」と聞いたとき、文字列検索では「authentication」という語を含むファイルしか当たりません。semantic indexがあれば、signIn や verifyCredentials のように語が違っても意味の近いファイルが見つかります。1.118より前は、GitHubかAzure DevOps（ADO）のリポジトリを開いたワークスペースだけが対象でした。

インデックスの作られ方と3種類の取得元

インデックスは自動で作られ、更新も自動です。VS Codeの公式ドキュメント「How Copilot understands your workspace」（原稿の承認日：2026年10月14日）では、取得元によって初回に使えるまでの時間が変わると説明しています。

すぐにインデックスを作り直したいときは、コマンドパレットで Build Codebase semantic index を実行します。インデックスの状態は、ステータスバーのCopilotアイコンから開くダッシュボードに表示されます。

海外の解説記事には、インデックスを「Remote・Local・Basic」の3種類に分け、ローカルは2,500ファイルまでと説明しているものが今も残っています（2026年6月公開の記事にもあります）。現行の公式ドキュメントにはこの区分も上限もありません。1.142.0のCopilot拡張の設定一覧にも、そうした記事が紹介する github.copilot.codebase という設定はありません。公式ドキュメントのGitHub上の更新履歴を見ると、1.118公開前日の2026年4月28日に、GitHub以外のコードは「External Ingestという機能で有料プランから段階展開中」という説明が、今の「Other workspaces」の説明に書き換えられています。この履歴から言えるのは、GitHub以外のコードの扱いが4月28日に変わったことまでです。古い記事にあるLocal・Basicの区分や2,500ファイルの上限が当時の正式な仕様だったかどうかは、この履歴だけでは確かめられません。現行版の挙動を調べるときは、記事の日付と、参照している公式ドキュメントの版を確認してください。

インデックスの対象から外れるフォルダとファイル

公式ドキュメントが挙げる除外は、.gitignore と files.exclude で除いたファイル、画像やPDFなどのバイナリ、.tmp や .out のような一部の拡張子だけです。実際の判定は、Copilot拡張のソース（1.142.0タグの workspaceFileIndex.ts）にもっと細かく書かれています。下の表のフォルダ・ファイル名・拡張子の判定は、手元のファイル索引と、GitHub以外のリポジトリをGitHubへ送る経路（External Ingest）の両方で使われます。GitHubやAzure DevOpsのリポジトリをサービス側で索引する場合には当てはまりません。

フォルダの判定は、ファイルの絶対パスのどこかに同じ名前の階層があるかどうかで行われ、大文字と小文字は区別されません。ワークスペースより上の階層も判定に含まれます。そのため、ソースコードを out や dist という名前のフォルダに置いているプロジェクトでは、そのコードが意味検索に出てきません。この場合はフォルダ名を変えるか、プロンプトでファイルを直接指定します。除外フォルダの一覧には Pods も入っていますが、比較の前にパスを小文字にしているため、大文字を含む Pods は実際には一致しません（1.142.0時点）。

ファイルの大きさの扱いは経路で違います。手元のファイル索引は1.5MB（1.5×1024×1024バイト）を超えるファイルを先頭1.5MBで切り詰めて読みます。GitHubへ送る経路は、パスとサイズで取り込めるかを別に判定しており、その上限はソースから読み取れません。巨大な生成コードやダンプは、意味検索で後半まで拾われる前提にしない方が安全です。

2026年10月16日の公式ドキュメント更新（GitHub上の原稿）では、「インデックスは関連する断片を探すためのもので、ワークスペース全体を毎回モデルに送るわけではない」という説明と、必要なファイルが分かっているなら明示的に参照するよう促す説明が加わりました。インデックスがあっても、Copilotが全ファイルを読んでいるわけではありません。

組織アカウントでは既定で無効になる理由

1.118のリリースノートは「rolled out to all users」と書いています。ただし、GitHub以外のリポジトリで使えるかどうかは契約形態で分かれます。GitHubのドキュメント「Indexing repositories for GitHub Copilot」によると、この機能はワークスペースのファイルをGitHubへアップロードして検索できるようにする仕組みで、ポリシーの既定は無効です。Copilot BusinessやCopilot Enterpriseでは、組織またはEnterpriseのオーナーがポリシー「Semantic indexing for non-GitHub repositories」を Enabled にするまで、メンバーは使えません。ポリシーが Unconfigured のままなら使えないままです。

提供範囲はGitHub.comに限られ、GHE.com（データレジデンシー版）とGitHub Enterprise Serverでは使えません。社外に出せないコードをGitLabや社内サーバーで管理している組織では、ポリシーを有効にすることが「コードをGitHubへ送ってよい」という判断と同じ意味になります。そのため、有効化は開発チームではなく情報管理の責任者が判断すべき事項です。GitHubのドキュメントは、インデックスしたリポジトリをCopilotのモデル学習には使わないと明記しています。判断材料になるのは学習ではなく、コードがGitHubに置かれることそのものです。

組織でCopilotを使う範囲とデータの扱いを決める段階なら、生成AI導入支援で利用ルールの設計から相談できます。

アップロードしたインデックスの削除と診断コマンド

GitHubのドキュメントには「アップロードする」とは書かれていますが、消し方は書かれていません。Copilot拡張には、コマンドパレットのDeveloperカテゴリに次の2つのコマンドがあります。どちらも1.118.0と1.142.0のpackage.jsonに定義されています。

• Developer: Delete External Ingest Codebase Index … 今のワークスペースについてGitHubへ送ったインデックスを削除する。
• Developer: Collect Workspace Index Diagnostics … インデックスの状態を診断用に集める。Issueを立てる前に使う。

1.142.0のソース（externalIngestIndex.ts）では、削除コマンドはサーバー側のファイルセットと、どこまで送ったかを示すチェックポイントを消します。手元に置かれたファイルのハッシュのキャッシュは残します。インデックスは自動で作られる仕組みなので、機能が有効なままなら削除後に再び作られます。送らせたくないなら、先に組織のポリシーを無効にするか、個人アカウントならそのワークスペースではCopilotを使わない判断が必要です。

「No indexable repos found」エラーの読み方

Build Codebase semantic indexを実行すると、「Could not build codebase semantic index. No indexable repos found and support for indexing non-GitHub repos is not available」と表示されることがあります。GitHubのリポジトリを開いていても出るため、原因が分かりにくいエラーです。microsoft/vscodeのIssue #315276では、2026年6月2日にメンテナーが原因を説明しています。報告の時点では、個人のCopilotユーザーの約25%で、GitHub以外のリポジトリ向けの機能が一時的に無効になっていました。回答時点では個人アカウントの全員で有効になったと説明されており、組織・Enterpriseのユーザーは上記のポリシーを有効にする必要があります。

このIssueで説明された原因は、当時の個人向けの提供状態と組織ポリシーです。組織アカウントなら、まず管理者にポリシーの状態を確認します。1.122以降でも症状が続く場合は、新しいIssueで報告するようメンテナーが案内しています。インデックスが無くても、Copilotは文字列検索・grep・ファイル検索・言語機能で探索を続けます。公式ドキュメントは、これらの手段でも多くのプロンプトに正確に答えられると説明しています。ただし、意味で探す検索は使えません。

#codebaseとgithubTextSearchの使い分け

プロンプトに #codebase を付ける必要は基本的にありません。エージェントは必要に応じてsemantic searchを自分で選びます。付けるのは、そのプロンプトで確実に意味検索を使わせたいときだけです。

1.118で追加された githubTextSearch ツールは逆の役割を持ちます。開いているワークスペースの外にある、GitHubリポジトリや組織全体のコードを、grepのように文字列の完全一致で検索するツールです。エラーメッセージやAPI名を他リポジトリで探す場面に向いています。既存の githubRepo ツールは、他リポジトリに対する意味検索を担当します。

github.copilot.chat.localIndex.enabledはChronicleの設定

github.copilot.chat.localIndex.enabled は名前に「index」を含むので、semantic indexの設定と誤解されがちです。実際には、1.118で実験的に入ったChronicleを動かすための設定です。Chronicleは、チャットのやり取り、ツール呼び出しで触ったファイル、参照したPRやIssueをローカルのSQLiteデータベースに記録します。semantic indexとは別の機能です。

1.118で使えたコマンドは3つです。/chronicle:standup は直近24時間のセッションからスタンドアップ用の報告を作り、/chronicle:tips は7日分の使い方を分析して改善点を示します。/chronicle [質問] は「昨日どのファイルを編集した？」のような自然文の問い合わせに答えます。

セッションをGitHubアカウントへ同期する chat.sessionSync.enabled は、1.119.0のソースで設定が追加され、1.123（2026年6月3日）のリリースノートで紹介されました。1.118.0には存在しない設定で、1.118時点ではローカル保存だけでした。それ以降の版では、設定によって履歴がクラウドにも保存されます。業務で使う場合は、次の既定値の違いに注意してください。

• localIndex.enabled の既定値は、1.118.0ではfalse、1.142.0のCopilot拡張のpackage.jsonではtrue（実験で値が変わる onExp 付き）。
• chat.sessionSync.enabled は、1.142.0のソースでも既定false（実験的）。localIndex.enabled がオンであることが前提の設定で、公式ドキュメントの設定一覧も既定を false と書いている。

自分の環境で同期がオンになっているかは、推測せず設定画面で確認してください。同期させたくないリポジトリは chat.sessionSync.excludeRepositories で除外できます。Copilot BusinessとEnterpriseでは、グループポリシー CopilotSessionSync を無効にすると同期がfalseに固定されます。

1.118で既定値が変わった設定と現行版との差

1.118で入った設定の多くは、その後の版で既定値が変わっています。下の表は、VS Codeのリポジトリで1.118.0タグと1.142.0タグ（2026年10月14日公開）のpackage.jsonを比べたものです。1.139.0（9月23日）とも比べましたが、4つの既定値は同じでした。

Copilot共著者の自動追加：1.117で有効化、1.119で既定offへ変更

1.118のリリースノートには「Copilot is automatically added as a co-author」とあり、Copilotがファイルを変更したコミットには Co-authored-by: トレーラーが自動で付きました。この設定には経緯があります。Microsoftが2026年5月5日に公開したIssue #314311によると、1.110で追加された時点の既定値はoffでした。1.117（4月22日に展開開始）で既定値をallに変えたところ、Copilotが関与していない補完まで共著者として記録する不具合がありました。この不具合は、AI機能を無効にする disableAIFeatures をオンにしていても起きていました。そこで1.118では既定値をchatAndAgentに絞っています。

最終的に、2026年5月3日にマージされたPR #313931で既定値はoffに戻りました。1.119.0（5月6日）からは、disableAIFeatures がオンなら設定値にかかわらず共著者行は付きません。1.119のリリースノートはこの変更に触れていません。Microsoftは今後、共著者行を付ける前に必ず利用者の同意を求める方針を示しています。

このため、1.117と1.118系を使っていた2026年4月下旬から5月上旬のコミットには、Copilotの共著者行が付いている場合があります。とくに1.117の時期のものは、Copilotを使っていない変更に付いた可能性があります。共著者行だけでは実際にCopilotを使ったかどうかを判定できないので、監査では当時のVS Codeの版と変更内容をあわせて確認してください。今後も付けたい場合は、git.addAICoAuthor を chatAndAgent（チャットとエージェントの変更）か all（インライン補完も含む）に明示的に設定します。

Copilot CLIのリモート操作

リモート操作は、手元のマシンで動いているCopilot CLIのセッションを、GitHub.comかGitHubモバイルアプリから確認・承認・指示できる機能です。1.118では設定をオンにしたうえで、Copilot CLIのチャットに /remote on と入力して開始しました。/remote で状態を確認し、/remote off で止めます。1.142.0では通常の既定値がtrueになり、実験的の扱いも外れています。ただし、package.jsonではAgentsウィンドウ向けの既定値がfalseに上書きされています。

github.copilot.chat.skillTool.enabledとcontext: fork

スキルの専用コンテキストは、スキルを別のサブエージェントで動かし、結果だけを元の会話に返す機能です。大量のファイルを読むスキルでも、本来の会話のコンテキストが埋まりません。SKILL.md の先頭に次のフロントマターを置き、その後にレビュー手順などのスキル本文を記述します。

---
name: pr-review
description: Review a pull request for code quality and correctness.
context: fork
---

github.copilot.chat.skillTool.enabled がオフのままだと、VS Codeは「The ‘context: fork’ attribute requires the skill tool to be enabled (github.copilot.chat.skillTool.enabled).」という警告を出します。これはエラーではなく警告なので、スキル自体は読み込まれます。ただし、forkの指定は効きません。この設定は1.142.0でも既定false・実験的のままです。forkを使うなら明示的にオンにします。

オンにして変わるのはforkだけではありません。1.142.0のCopilot拡張のソース（skillTool.tsほか）を読むと、違いは次のとおりです。

スキルを数十本入れている環境でオンにすると、名前・説明文・ファイルパスを含む一覧が約15,000字（JavaScriptの文字列長）を超えた時点で、それ以降のスキルは名前だけになります。名前の列挙も5,000字までで、残りは「and N more」と件数だけが渡ります。説明文で使いどころを判断させているスキルは、呼ばれにくくなります。よく使うスキルの説明文は短くしておくのが無難です。forkで動くサブエージェントには、ソース上は会話の最初のターン（turns[0]）の発言がタスクとして渡されます。長い会話の途中でforkのスキルを呼ぶと、直前の依頼ではなく最初の依頼が渡る可能性があるので、forkのスキルは新しいチャットで呼ぶ方が確実です。

forkかどうかの判定は、フロントマターを正規表現で読む簡易なものです。ソースの判定関数を手元のNode.jsで動かして確かめたところ、次の2つはforkにならず、通常の読み込みになりました。

• SKILL.mdの改行がCRLF（Windowsで作ったファイルの既定）
• context: "fork" のように値を引用符で囲んだ書き方

skillToolをオンにした状態ではどちらも警告が出ません。forkが効かないときは、改行コードをLFにし、値を引用符なしの fork にしてください。

ワークスペースの.mcp.jsonとMCPサーバーの重複排除

1.118から、ワークスペース直下の .mcp.json にMCPサーバーを宣言できるようになりました。Copilot CLIと同じ形式です。同じ名前のMCPサーバーが複数の場所に定義されているときは、最も具体的な定義だけが有効になり、ほかは無効になります。どのサーバーが有効かは、拡張機能ビューで @mcp @installed を検索するか、Chat: Open Customizations で確認します。

devcontainer-lock.jsonの既定化とCIでの扱い

devcontainer-lock.json は、devcontainer.json に書いたDev Container Featureの実際の版とチェックサムを記録するファイルです。npmの package-lock.json と同じ役割を持ちます。1.118では、Dev Containers拡張の設定 dev.containers.lockfile が既定でオンになりました。Featureを初めてインストールしたときの版とSHA-256チェックサムが記録され、以後はそのFeature成果物に固定されます。ただし、Featureのインストール処理が取得するツールをlatest指定にしている場合、そのツールの版まで固定されるわけではありません。これはサプライチェーン攻撃への対策です。Dev Containerの仕組みそのものはDev Containerのメリットと設定の記事で解説しています。

ロックファイルに記録される項目

Dev Container仕様のロックファイル定義では、Featureごとに version（完全な版番号）、resolved（OCIのFeatureならsha256付きの識別子）、integrity（成果物のSHA-256）を記録し、依存があれば dependsOn も記録します。ファイルは devcontainer.json と同じフォルダーに置かれます。仕様書の例は次のとおりです。

{
    "features": {
        "ghcr.io/devcontainers/features/node:1": {
            "version": "1.0.4",
            "resolved": "ghcr.io/devcontainers/features/node@sha256:567d704b3f4d3eca3acee51ded7c460a8395436d135d53d1175fb565daff42b8",
            "integrity": "sha256:567d704b3f4d3eca3acee51ded7c460a8395436d135d53d1175fb565daff42b8"
        }
    }
}

ローカルのFeatureと、廃止されたGitHub Releases形式のFeatureは記録されません。devcontainer.json のFeatureに新しい版が出ると、エディターにCode Lensが表示されます。Dependabotを設定すれば、ロックファイルを更新するPRも自動で作れます。

devcontainer CLIでロックファイルを強制する方法

VS Codeの拡張機能とは別に、CIで使うdevcontainer CLIでも、0.87.0（2026年5月）でロックファイルが実験機能から正式機能になりました。build と up を実行すると既定でロックファイルが作られ、--frozen-lockfile と --no-lockfile の2つのフラグが追加されています。以前の --experimental-lockfile は警告付きで引き続き使えます。

# ロックファイルが無い、または内容と違えば失敗させる（CI向け）
devcontainer build --workspace-folder . --frozen-lockfile

# ロックファイルを作らず、検証もしない
devcontainer up --workspace-folder . --no-lockfile

ロックファイルを使うなら、リポジトリにコミットし、CIでは --frozen-lockfile を付けてください。コミットしないと開発者ごとに別のロックファイルが作られ、版を固定する意味がなくなります。--no-lockfile と --frozen-lockfile は同時に指定できず、CLIがエラーで止まります。

1.118.1で報告された個人設定の混入

既定化の直後に、ユーザー設定 dev.containers.defaultFeatures で入れている個人用のFeatureが、プロジェクトの devcontainer-lock.json に書き込まれる問題が報告されました（microsoft/vscode-remote-release Issue #11616、1.118.1で報告、2026年5月5日にcompletedでクローズ）。devcontainer CLIでは0.86.1で「--additional-features で渡したFeatureをロックファイルに書かない」修正が入っています。仕様上、ロックファイルには devcontainer.json に指定したFeatureと、その依存Featureが記録されます。1.118系の時期に作ったロックファイルをコミットしている場合は、devcontainer.json の指定にも依存関係にも含まれない、個人設定由来のFeatureが記録されていないか確認してください。含まれていたら、現行版で作り直します。

トークン効率化とCopilotの従量課金への備え

GitHubは2026年4月27日に、Copilotを6月1日から従量課金へ移行すると発表しました。1.118のリリースノートでは、これに合わせたトークン削減策がまとめて説明されています。

キャッシュされた入力は、Anthropicモデルでは通常の約10分の1の単価で課金されるため、長いセッションほど効果が大きくなります。agentic executionツールは、テストやビルドのターミナル実行を小さなモデルに任せ、長い出力をメインのモデルに渡さない仕組みです（1回の呼び出しで実行するコマンドは最大10回）。

GPTモデル向けのツール検索を有効にする github.copilot.chat.responsesApi.toolSearchTool.enabled と、キャッシュ境界の設定 github.copilot.chat.anthropic.cacheBreakpoints.lastTwoMessages は、1.118で導入されました。どちらも、1.139.0と1.142.0のCopilot拡張のpackage.jsonには定義が残っていません。1.118の記事やリリースノートを見てこの2つを設定しても、現行版では効きません。

Agentsアプリ・企業向けポリシー・TypeScript 7の扱い

Visual Studio Code Agentsアプリ（Insiders限定）

Agentsアプリは、複数のリポジトリでエージェントを並行して動かすための専用アプリです。1.118ではVS Code Insidersにだけ同梱されていました。Insidersのタイトルバーの Open in Agents から開けるようになり、Claudeエージェント、ブラウザー版（insiders.vscode.dev/agents、code-insiders tunnel で接続）、差分表示のレイアウト切り替えが加わっています。Stableでエージェントウィンドウがプレビュー提供されたのは1.120からで、その内容はVS Code 1.120の記事にまとめています。

ChatApprovedAccountOrganizationsとサンドボックスの読み取り制限

ChatApprovedAccountOrganizations は、チャットとAI機能を、承認したGitHub組織のメンバーだけに使わせるデバイスポリシーです。2つの条件が揃うまでチャットは有効になりません。承認済み組織に所属するアカウントでサインインしていること、そしてアカウント単位のポリシーの解決が終わっていることです。確認できない間は機能を止めるフェイルクローズ型なので、承認済み組織に所属しないアカウントによる、その端末のVS Codeでのチャット・AI機能の利用を制限できます。

同じ1.118で、サンドボックス内で実行するコマンドから $HOME 以下を自由に読める挙動もなくなりました。$HOME配下では、ワークスペースとサンドボックスの一時フォルダーに既定の読み取り権限があり、実行するコマンドに応じたパスにも権限が追加されます。

TypeScript 7.0 BetaとEdit Modeの廃止予告

1.118では、TypeScript Native preview拡張を入れるだけでTypeScript 7.0 Betaを試せるようになり、TS 6.0との切り替えも簡単になりました。VS Code自身の開発では、約6,000ファイルの型チェックが約60秒から約10秒に短くなったと書かれています。TypeScript 7はその後、npmで7.0.2（2026年7月8日）が正式版として公開されています。移行の要点はTypeScript 7の記事で扱っています。

1.118のリリースノートには、Edit Modeの廃止予告も載っています。chat.editMode.hidden による一時的な再有効化は、1.126で終了するという予告です。実際に1.126（2026年6月24日）でこの設定は削除され、Agent modeを無効化するポリシーを受けている環境だけに旧Edit Modeが残っています。詳細はGitHub Copilot EditsとEditモードの記事を参照してください。

1.118のまま使い続けるリスクと更新の判断

2026年10月14日の1.142.0までに、1.119から1.142まで24のマイナーバージョンが公開されています。1.118に残る理由は、ほぼありません。semantic indexについては、1.122以降でも同じエラーが続く場合に新しいIssueで報告するよう案内されています。共著者の自動追加は1.119で既定offに戻り、Edit Modeも1.126で削除済みです。

拡張機能の互換性などで1.118に固定している場合は、少なくとも次の2点を確認してください。

• git.addAICoAuthor を明示的にoffにする（1.118系の既定はchatAndAgent）。
• コミット済みの devcontainer-lock.json に個人用のFeatureが混入していないか確認する。

現在の版は code --version の1行目に出ます。

よくある質問

codebase semantic indexとは何ですか？

Copilotがコードを意味で検索するためのインデックスです。GitHubとAzure DevOpsのリポジトリでは、それぞれのサービス側で作られます。1.118からは、それ以外のワークスペースでもCopilotが数分で構築するようになりました。組織・Enterpriseのアカウントでは、GitHub以外のリポジトリを対象にするにはオーナーによるポリシーの有効化が必要です。

github.copilot.chat.localIndex.enabledは何の設定ですか？

チャット履歴を記録して /chronicle コマンドで分析するChronicleの設定で、semantic indexとは関係ありません。1.118.0では既定false（実験的）でしたが、1.142.0のpackage.jsonでは既定trueです。履歴をGitHubへ同期する chat.sessionSync.enabled は、この設定がオンであることが前提です。

devcontainer-lock.jsonはコミットすべきですか？

コミットを推奨します。版とチェックサムを固定するためのファイルなので、コミットしないと開発者ごとに別の版が入ります。CIでは、devcontainer CLI 0.87.0以降の --frozen-lockfile で不一致を検出できます。

VS Code 1.118のリリース日はいつですか？

1.118.0は2026年4月29日、修正版の1.118.1は2026年4月30日に公開されました。次の1.119.0は2026年5月6日です。

インデックスしたコードはCopilotの学習に使われますか？

GitHubのドキュメントは、インデックスしたリポジトリをモデルの学習には使わないと明記しています。ただし、GitHub以外のリポジトリをsemantic indexの対象にすると、ファイルはGitHubへアップロードされます。送ったインデックスは「Developer: Delete External Ingest Codebase Index」で削除できます。

関連記事

• VS Codeの最新バージョンは1.135｜確認方法・週次リリースの仕組みとVisual Studioとの違い
• VS Code 1.120の新機能｜エージェントウィンドウの使い方とMarkdown差分プレビュー
• VS Code v1.109の新機能｜エージェント機能の再編とClaude連携
• Dev Container（devcontainer）のメリットとは｜Dockerで開発環境を統一する仕組みと設定【2026年版】
• VS CodeでGitHub Copilotを使うには？導入・SSO設定・使い方・料金を解説【2026年10月版】