VS Codeでタスクや機能が使えない原因は?Workspace Trustを安全に許可する方法

VS Codeでフォルダーを開いた直後に、タスク、デバッグ、ターミナル、拡張機能、AIエージェントなどが使えなくなった場合は、Workspace Trustによる「制限モード」が原因の可能性があります。

信頼を許可してよいのは、取得元とフォルダー内の内容を確認できる場合だけです。 出所が分からないファイル、メールやチャットで受け取ったZIP、内容を確認していないリポジトリは、すぐに信頼せず制限モードのまま開いてください。制限モードでもソースコードの閲覧と編集はでき、確認後に信頼へ切り替えられます。([Visual Studio Code][1])

目次

VS Codeの制限モードで実行できないときのWorkspace Trust確認

Workspace Trustは、開いたプロジェクト内のコードや設定をVS Codeと拡張機能が実行してよいか、利用者が判断するための仕組みです。

未知のフォルダーを制限モードで開くと、自動的なコード実行につながる機能が無効化または制限されます。単なるエラーではなく、意図しないプログラムの実行を防ぐための動作です。([Visual Studio Code][1])

機能制限モードで起こること
タスクタスクの一覧表示や実行時に、フォルダーを信頼するよう求められる
デバッグデバッガーの起動が制限される
統合ターミナル初期状態では開く前に信頼確認が表示される
ワークスペース設定実行ファイルのパスなど、一部の設定が適用されない
拡張機能無効化されるか、一部機能だけに制限される
AIエージェント信頼していないワークスペースでは実行されない

現在の信頼状態を確認する

次の手順でWorkspace Trustの管理画面を開きます。

  1. CtrlShiftPでコマンドパレットを開きます。
  2. Workspace Trust、または「ワークスペースの信頼」に相当する語を入力します。
  3. Workspaces: Manage Workspace Trustを選択します。
  4. 現在のフォルダーが「信頼済み」か「制限モード」かを確認します。

制限モード中は、画面上部のバナーにある管理リンクや、ステータスバーの制限モード表示からも管理画面を開けます。表示名はVS Codeのバージョンや表示言語によって多少異なることがあります。([Visual Studio Code][1])

親フォルダーから信頼を継承していないか確認する

Workspace Trustでは、親フォルダーを信頼すると、その下にあるすべてのサブフォルダーも信頼されます。

たとえば、次のフォルダーを信頼しているとします。

C:\Users\user\Projects

この場合、次のフォルダーは個別に操作していなくても信頼済みになります。

C:\Users\user\Projects\company-app
C:\Users\user\Projects\sample-code
C:\Users\user\Projects\downloaded-project

Workspace Trustの管理画面にある「Trusted Folders & Workspaces」の一覧を確認してください。現在開いているフォルダーは強調表示されます。

「信頼しない」に戻すボタンが表示されない場合は、親フォルダーから信頼を継承している可能性があります。その場合は、一覧から広すぎる親フォルダーの信頼を削除し、本当に信頼できるプロジェクトだけを個別に登録します。([Visual Studio Code][1])

信頼を許可してよいか判断する基準

「自分が使うプロジェクトだから信頼する」ではなく、取得元と実行内容を説明できるかで判断します。

状況判断の目安
自分で新規作成したフォルダー基本的には信頼候補。ただし外部からコピーしたスクリプトがないか確認する
自分や所属組織が管理するリポジトリ接続先と変更内容を確認したうえで信頼する
信頼できる公式組織のリポジトリリポジトリURLと所有者を確認してから信頼する
メールやチャットで届いたZIP送信者だけで判断せず、内容を確認するまで信頼しない
ブログや掲示板からダウンロードしたサンプル配布元と実行内容が分かるまで制限モードを維持する
AIが生成・変更したプロジェクトタスク、スクリプト、設定ファイルの変更を確認してから信頼する
親フォルダーの信頼で自動的に信頼済み意図した継承か確認し、必要なら親フォルダーの信頼を解除する

有名なサービスから取得したコードでも、フォーク先、改変版、広告経由のダウンロードファイルなどが混在することがあります。「GitHubにあるから安全」とは限りません。

Gitリポジトリなら接続先と変更状態を確認する

Gitを利用しているプロジェクトでは、ターミナルを実行しなくても、VS Codeのソース管理画面やファイル内容からある程度確認できます。

別の安全な環境で確認できる場合は、次のコマンドも役立ちます。

git remote -v
git status

git remote -vでは接続先リポジトリを、git statusではローカルで変更されているファイルを確認できます。

ただし、接続先URLが正しいことだけでは安全性を保証できません。リポジトリ内のスクリプトや設定ファイルも確認する必要があります。

信頼する前に確認したいファイル

Workspace Trustを許可すると、タスクや拡張機能などがプロジェクト内の設定を利用して処理を実行できるようになります。少なくとも、次のファイルが存在する場合は内容を確認してください。

ファイル・場所主な確認内容
.vscode/tasks.json実行されるコマンド、シェル、外部プログラム
.vscode/launch.jsonデバッグ時に起動するプログラムや引数
.vscode/settings.json実行ファイルのパス、保存時の処理、拡張機能の設定
package.jsonscriptsに登録されたビルド、テスト、インストール処理
.ps1.bat.cmdPowerShellやWindowsコマンドの実行内容
.shLinuxやmacOSで実行されるシェルコマンド
Makefile、ビルド設定ビルド時に起動する外部ツール
.envや構成ファイルAPIキー、トークン、接続先などの機密情報

VS Codeのタスクは、ワークスペース内の.vscode/tasks.jsonからシェルコマンドやプロセスを起動できます。タスク名が「Build」や「Test」でも、実際に何を実行するかはcommandなどの設定で決まります。([Visual Studio Code][2])

特に次のような処理が含まれている場合は、目的を確認してから信頼してください。

  • 外部サイトからファイルをダウンロードして、そのまま実行する
  • PowerShellやシェルへ長い文字列を渡して実行する
  • 管理者権限を要求する
  • ユーザーフォルダーやシステム設定を変更する
  • .envや認証情報を読み取って外部へ送信する
  • ファイルを大量に削除または上書きする
  • パッケージのインストール時に追加スクリプトを実行する

内容を理解できないコマンドがある場合は、タスクを動かすためだけに信頼を許可しないことが重要です。

@workspaceUnsupportedで制限中の拡張機能を確認する

制限モードでは、Workspace Trustに対応していない拡張機能が無効化されることがあります。また、拡張機能によっては一部の機能だけが制限されます。

確認方法は次のとおりです。

  1. Workspace Trustの管理画面を開きます。
  2. 無効または制限されている拡張機能のリンクを選択します。
  3. 拡張機能画面に@workspaceUnsupportedフィルターが適用されていることを確認します。
  4. 「Disabled in Restricted Mode」または「Limited in Restricted Mode」の拡張機能を確認します。

拡張機能画面の検索欄へ、直接次の文字列を入力しても確認できます。

@workspaceUnsupported

拡張機能が表示されない、コマンドが消えた、入力補完やフォーマットが動かない場合は、この一覧を最初に確認すると原因を切り分けやすくなります。([Visual Studio Code][1])

拡張機能の制限を手動で解除する場合の注意点

extensions.supportUntrustedWorkspaces設定を使うと、個別の拡張機能を信頼していないワークスペースでも動作させられる場合があります。

ただし、拡張機能の開発者が安全上の理由から制限している可能性があります。単に機能を使えるようにする目的で、すべての拡張機能を一律に許可するのは避けてください。

先に次の点を確認します。

  • 拡張機能の提供元を信頼できるか
  • なぜWorkspace Trustが必要なのか
  • 制限モードで使えない機能は何か
  • ワークスペース内の実行ファイルや設定を読み込むか
  • 最近の更新履歴や既知の問題に不審な点がないか

拡張機能は、ワークスペース内の依存関係や設定を利用してコードを実行することがあります。そのため、制限を上書きする判断は、フォルダーを信頼する場合と同様に慎重に行う必要があります。([Visual Studio Code][3])

適用されていないワークスペース設定を確認する

制限モードでは、コード実行につながる可能性があるワークスペース設定の一部が適用されません。

Workspace Trustの管理画面から、適用されていない設定のリンクを選ぶと、設定画面が次のフィルターで絞り込まれます。

@tag:requireTrustedWorkspace

ここに表示される設定を確認すれば、「設定したはずなのに動作しない」「実行ファイルのパスが反映されない」といった問題がWorkspace Trustによるものか判断できます。([Visual Studio Code][1])

親フォルダーは必要以上に信頼しない

複数のプロジェクトを扱う場合は、信頼するフォルダーと未確認のフォルダーを分けると管理しやすくなります。

C:\Development
├─ TrustedProjects
│  ├─ company-system
│  └─ personal-app
└─ ForReview
   ├─ downloaded-sample
   └─ unknown-project

TrustedProjectsだけを親フォルダーとして信頼し、ForReviewは信頼しない運用にします。

一方、次のような範囲の広すぎるフォルダーを信頼するのは避けてください。

C:\Users\user
C:\Users\user\Downloads
C:\Users\user\Desktop
C:\

ダウンロードしたばかりのファイルや、一時的に受け取ったプロジェクトまで自動的に信頼されるためです。

制限モードは完全なセキュリティサンドボックスではない

制限モードは、自動的なコード実行を抑えるための追加の防御機能です。OSから完全に隔離された仮想環境や、すべての動作を遮断するセキュリティサンドボックスではありません。

特に、悪意のある拡張機能が制限モードを無視してコードを実行することまで、Workspace Trustだけで完全に防げるわけではありません。拡張機能自体も、信頼できる提供元のものだけをインストールする必要があります。([Visual Studio Code][1])

安全性をさらに高めたい場合は、重要なデータが入っていない検証用PC、仮想マシン、Dev Containerなど、実行環境を分離する方法も検討します。

AIエージェントを動かすためだけに信頼しない

VS CodeのAIエージェントは、ファイルの作成・変更・削除や、ターミナルコマンドの実行などを行う場合があります。そのため、未確認のプロジェクトは制限モードで開き、内容を確認するまでエージェントを実行しないことが基本です。([Visual Studio Code][4])

Workspace Trustを許可した後も、次のような運用は避けてください。

  • すべてのツールやコマンドを無条件で自動承認する
  • 内容を確認せず、エージェントが提案したコマンドを実行する
  • .env、秘密鍵、トークンを含むフォルダーで広範なアクセスを許可する
  • 出所不明のMCPサーバーや拡張機能を同時に有効化する
  • 変更内容を確認せず、そのままコミットやデプロイを行う

自動承認は操作を速くできますが、確認の機会を減らします。必要な権限だけを一時的に許可し、変更差分と実行コマンドを確認する方が安全です。([Visual Studio Code][4])

避けるべき対処方法

Workspace Trust自体を無効にする

次の設定を無効化すると、Workspace Trustによる確認を停止できます。

security.workspace.trust.enabled

しかし、タスクを動かすたびに確認するのが面倒という理由だけで無効化するのは推奨できません。未知のプロジェクトでもコード実行に関係する機能が利用可能になるためです。公式ドキュメントでも、Workspace Trustの無効化は推奨されていません。([Visual Studio Code][1])

ホームフォルダーやドライブ全体を信頼する

広い親フォルダーを信頼すると、その配下へ後から保存したプロジェクトも自動的に信頼されます。個別確認の仕組みが実質的に働かなくなるため、信頼範囲は必要最小限にします。

警告が出たら毎回「信頼する」を選ぶ

警告を消すことと、フォルダーが安全であることは別です。作業を進めるためだけに信頼するのではなく、取得元と実行内容を確認してから判断します。

制限モードなら何をしても安全だと考える

制限モードでも、ファイルの閲覧や編集は可能です。また、Workspace Trustに対応した拡張機能は動作する場合があります。制限モードを「完全に隔離された環境」と考えないでください。

信頼したのにタスクが使えない場合

Workspace Trustを許可してもタスクが表示されない場合は、別の原因を確認します。

ファイル単体ではなくフォルダーを開いているか

VS Codeのタスク機能は、ワークスペースフォルダーを開いている場合に利用できます。ファイルを1つだけ開いている状態では、タスク機能は利用できません。([Visual Studio Code][2])

次の操作でプロジェクトフォルダー全体を開きます。

ファイル → フォルダーを開く

tasks.jsonの場所を確認する

フォルダー固有のタスクは、通常は次の場所に保存されます。

プロジェクトフォルダー
└─ .vscode
   └─ tasks.json

別の階層にある場合や、JSONの構文が壊れている場合は、タスクとして認識されないことがあります。

必要な拡張機能が有効か確認する

npm、C#、Javaなどのタスクは、拡張機能や開発環境から提供される場合があります。

@workspaceUnsupportedフィルターを解除した通常の拡張機能画面で、必要な拡張機能がインストール済みか、無効化されていないか確認してください。

現在のフォルダーが本当に信頼済みか再確認する

似た名前の別フォルダーや、別のワークスペースファイルを開いている場合があります。Workspace Trustの管理画面で、強調表示されているパスが目的のプロジェクトと一致しているか確認します。

よくある疑問

自分で作成したフォルダーなら信頼してよいですか

自分で作成し、自分だけが内容を変更しているフォルダーなら、一般的には信頼しやすい状況です。

ただし、外部からコピーしたスクリプト、ダウンロードしたテンプレート、パッケージのサンプル設定などが含まれている場合は、その部分を確認してください。

GitHubからクローンしたリポジトリは信頼してよいですか

GitHubから取得したという事実だけでは判断できません。

リポジトリの所有者、クローン元URL、フォーク元、最近の変更内容、タスクやスクリプトを確認します。公式組織のリポジトリでも、似た名称の別リポジトリを取得していないか確認が必要です。

制限モードのままコードを編集できますか

コードの閲覧とテキスト編集は可能です。ただし、言語機能、デバッグ、タスク、拡張機能などの一部が利用できない場合があります。([Visual Studio Code][1])

一度信頼したフォルダーを元に戻せますか

Workspace Trustの管理画面で「信頼しない」を選ぶか、「Trusted Folders & Workspaces」の一覧から対象フォルダーを削除します。

「信頼しない」が表示されない場合は、親フォルダーの信頼を継承していないか確認してください。([Visual Studio Code][1])

まず現在の信頼状態と親フォルダーを確認する

VS Codeでタスクや機能が使えない場合は、最初にWorkspaces: Manage Workspace Trustを開きます。

そこで、次の順番で確認してください。

  1. 現在のフォルダーが制限モードか確認する
  2. 親フォルダーから信頼を継承していないか確認する
  3. @workspaceUnsupportedで制限中の拡張機能を確認する
  4. @tag:requireTrustedWorkspaceで適用されていない設定を確認する
  5. 取得元と実行内容を確認できたフォルダーだけを信頼する
  6. 不要な親フォルダーの信頼を削除する

判断に迷う場合は、制限モードを維持するのが安全です。必要なファイルを閲覧し、タスクや設定の内容を確認してから、対象のプロジェクトだけを信頼してください。
[1]: https://code.visualstudio.com/docs/editing/workspaces/workspace-trust “Workspace Trust”
[2]: https://code.visualstudio.com/docs/debugtest/tasks “Integrate with External Tools via Tasks”
[3]: https://code.visualstudio.com/api/extension-guides/workspace-trust “Workspace Trust Extension Guide | Visual Studio Code Extension API”
[4]: https://code.visualstudio.com/docs/agents/run/security “Secure AI-assisted development in VS Code”

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次