ChatGPTからローカル開発環境を触るためにDevSpace（npmパッケージ: @waishnav/devspace）を使っていて、今回 C:\Tools を新しく許可ルートへ追加しました。
先に結論を書くと、自分の環境では allowedRootsを増やしただけならChatGPT側の接続を削除・再登録する必要はありませんでした。
MCPのツール定義を増やしたときとは挙動が違います。
今回やったこと
DevSpaceの設定に C:\Tools を追加しました。
"allowedRoots": [
"C:\\Users\\<USER>\\Documents\\Codex",
"C:\\Users\\<USER>\\Documents\\Chrome拡張機能",
"C:\\Users\\<USER>\\Documents\\Firefox拡張機能",
"C:\\Users\\<USER>\\Documents\\obsidian-vault\\my_vault\\.obsidian\\plugins",
"C:\\Tools"
]
これで、MCPやSecure Tunnelまわりの保守用ファイルもChatGPTからDevSpace経由で読んだり編集したりできるようにする狙いです。
allowedRootsの変更だけなら再登録はいらなかった
以前、Obsidian用MCPに新しいツールを追加したときは、サーバー側を更新してもChatGPTに古いツール一覧が残りました。
そのときはChatGPT側の接続を一度削除し、同じTunnelを使って再登録したら新しいツール定義が反映されました。
今回は違いました。
allowedRoots を追加してDevSpaceサーバーを新しい設定で起動し直したあと、そのまま既存のChatGPT接続から C:\Tools を open_workspace できました。
つまり今回の切り分けはこうです。
- ツール名、input schema、descriptionなどMCPのtool schemaを変更した場合は、ChatGPT側で再登録が必要になることがある
- allowedRootsのようなランタイム設定だけなら、まずサーバー再起動で確認する
少なくとも今回の環境では後者でした。
Windowsでは「Scheduled Taskを再起動した＝実プロセスも再起動した」とは限らなかった
ここで一度ハマりました。
Stop-ScheduledTask → Start-ScheduledTask を実行したので再起動できたと思っていたのですが、7676番ポートを見たら古いNodeプロセスがそのまま残っていました。
実際に確認すると、プロセスの起動日時は数日前のまま。
そのため、新しい config.json に C:\Tools が入っていても、動いているDevSpaceは古い設定を保持していました。
最終的には7676番をListenしているPIDを確認して、その古いプロセスを終了。Scheduled Taskから起動し直して、新しい起動日時になったことまで確認しました。
設定変更後に挙動が変わらないときは、設定ファイルだけでなく 実際にどのプロセスがポートを握っているか まで見るのが早いです。
Windows PowerShell 5.1 + UTF-8 BOMなしも地味に罠だった
もう一つ。
config.json には Chrome拡張機能 や Firefox拡張機能 という日本語パスが入っていました。
Windows PowerShell 5.1で
Get-Content $configPath -Raw | ConvertFrom-Json
と読んで書き戻したところ、日本語部分が文字化けしました。
今回はバックアップがあったので戻せましたが、日本語パス入りJSONを触るなら System.IO.File.ReadAllText(..., UTF8) と WriteAllText(..., UTF8) でエンコーディングを明示した方が安全でした。
C:\Tools 全体を許可するならAGENTS.mdも置いた
C:\Tools にはMCP、Tunnel、自動起動スクリプト、通知基盤などが入っています。
便利な反面、触れる範囲としてはかなり強いので、今回は C:\Tools\AGENTS.md を置いて、credentialやtokenを表示しない、Tunnelを勝手に削除・再作成しない、自動起動設定を安易に変更しない、といったガードを追加しました。
ただ、ここでも一つ発見がありました。
C:\Tools をworkspaceとして開けば親の AGENTS.md は読み込まれますが、C:\Tools\obsidian-vault-mcp-wrapper のようなサブフォルダを直接workspaceとして開くと、親の C:\Tools\AGENTS.md は自動では読み込まれませんでした。
そのため、直接workspaceとして開く可能性がある各フォルダにも用途別の AGENTS.md を置いています。
今回の運用ルール
自分の環境では、今後はこうします。
- allowedRootsや通常設定だけを変更した場合は、まずサーバーの実プロセスを再起動する
- ChatGPT側の接続はそのままで
open_workspaceできるか確認する - tool schemaを変えたときだけ、必要に応じてChatGPT側の再登録を試す
- 広いルートを許可する場合は、その配下にAGENTS.mdで保守ルールを置く
MCPをいじっていると「反映されない＝とりあえず接続を作り直す」になりがちですが、今回みたいに設定変更だけならそこまでやらなくてよさそうです。