chat.hookFilesLocations: rejects UNC/absolute paths inconsistently vs chat.pluginLocations + hooks inside agent plugins should be auto-discovered

[jagoqui]

Summary

Two related issues with chat.hookFilesLocations in VS Code Copilot Chat:

1. Bug: chat.hookFilesLocations rejects UNC paths and absolute paths that chat.pluginLocations already accepts — inconsistent validation.
2. Feature request: Hooks defined inside a registered agent plugin should be auto-discovered, just like skills, agents, and MCP servers are already discovered automatically from plugin directories.

---

Bug: chat.hookFilesLocations rejects UNC/absolute paths (inconsistent with chat.pluginLocations)

Error

When adding a UNC path (e.g., //wsl.localhost/Ubuntu/home/user/project/.agents/hooks) to chat.hookFilesLocations, the VS Code Settings UI shows:

"Paths must be relative or start with '~/'. Absolute paths and '' separators are not supported."

But chat.pluginLocations accepts the same paths

The exact same UNC path format (e.g., \\wsl.localhost\Ubuntu\home\jaidiver_gomez\cache\sura-toolkit\.agents) is accepted by chat.pluginLocations without any validation error.

Screenshots

chat.hookFilesLocations — UNC path rejected (see red error banner):

chat.pluginLocations — Same UNC path format accepted without error:

Steps to Reproduce

1. Open VS Code Settings (Ctrl+,) → search for chat.hookFilesLocations
2. Click Add Item and enter a UNC path: //wsl.localhost/Ubuntu/home/<user>/project/.agents/hooks
3. Observe the red validation error: "Paths must be relative or start with '~/'. Absolute paths and '' separators are not supported."
4. Now open settings for chat.pluginLocations
5. Click Add Item and enter the equivalent UNC path: \\wsl.localhost\Ubuntu\home\<user>\project\.agents
6. Observe: no error shown, path is accepted

Expected Behavior

Both settings should apply consistent path validation rules. chat.hookFilesLocations should support the same formats that chat.pluginLocations already accepts, including:

• UNC paths: //wsl.localhost/...
• Absolute Windows paths: C:\Users\...
• Absolute Linux paths from WSL: /home/user/...

This is especially important for users who run VS Code on Windows with WSL2, where project files live in the Linux filesystem and are accessed via UNC paths.

---

Feature Request: Auto-Discover Hooks from Registered Agent Plugins

This inconsistency highlights a deeper UX gap: hooks defined inside an agent plugin are not auto-discovered, even when that plugin is already registered in chat.pluginLocations.

Current behavior — plugin capabilities are inconsistently discovered

When a plugin directory is registered in chat.pluginLocations, VS Code automatically discovers:

• ✅ MCP servers (from .mcp.json inside the plugin)
• ✅ Skills (from skills/ subdirectory)
• ✅ Agents and prompt files

But:

• ❌ Hooks (hooks.json inside the plugin) are ignored — user must additionally register the hook path manually in chat.hookFilesLocations

This means users must maintain redundant configuration:

1. Register the plugin in chat.pluginLocations (gives skills, agents, MCP)
2. Also manually add the plugin's hook path in chat.hookFilesLocations (gives hooks)

And step 2 currently fails for WSL/UNC paths due to the bug described above.

Proposed Behavior

When a plugin directory is registered in chat.pluginLocations, VS Code should automatically discover and register any hook definition files found in the plugin's standard hook locations — consistent with how other plugin capabilities are discovered today.

Current vs. Expected Flow

Current:

User adds plugin to chat.pluginLocations
  → Skills auto-discovered      ✅
  → Agents auto-discovered      ✅
  → MCP servers auto-discovered ✅
  → hooks.json IGNORED          ❌ (requires separate manual step)

User must ALSO add hook path to chat.hookFilesLocations
  → May fail with UNC path validation error ❌

Expected:

User adds plugin to chat.pluginLocations
  → Skills auto-discovered      ✅
  → Agents auto-discovered      ✅
  → MCP servers auto-discovered ✅
  → hooks.json auto-discovered  ✅ (no extra step needed)

---

Environment

• VS Code Version: 1.114.0
• OS: Windows 11 with WSL2 (Ubuntu)
• Extension: GitHub Copilot Chat

Related Issues / Docs

• chat.plugins.paths: Avoid absolute paths #297365 — chat.plugins.paths: Avoid absolute paths (closed, 1.111.0)
• chat.pluginLocations: Allow workspace-relative paths in workspace settings (not just MACHINE scope) #303853 — chat.pluginLocations: Allow workspace-relative paths in workspace settings
• VS Code Hooks documentation
• VS Code Agent Plugins documentation

[connor4312]

Code should automatically discover and register any hook definition files found in the plugin's standard hook locations

This is the case, can you share an example of a plugin that you have which isn't working?

[aeschli]

For VS Code user settings to be sharable across machines with settings sync and remotes (WSL, devcontainers, SSH) we avoid machine dependent paths.

[jagoqui]

Hi team 👋

Just to clarify the behavior I was originally referring to: the `chat.pluginLocations` setting (Plugin Locations) already accepts UNC paths — for example, WSL paths like `\wsl.localhost\Ubuntu\home\user.cache\sura-toolkit.agents` — and VS Code discovers plugins from them correctly.

My suggestion is that hooks (or any similar discovery mechanism) should accept the same UNC path format, consistent with how `chat.pluginLocations` already handles it. This would be especially useful in WSL + Windows setups where plugins or agents live under UNC-accessible paths.

Here is a screenshot showing `chat.pluginLocations` accepting a UNC path successfully:

Thanks for considering this!

[aeschli]

This is especially important for users who run VS Code on Windows with WSL2, where project files live in the Linux filesystem and are accessed via UNC paths.

That sounds very strange, why do you do that? I would expect you use the WSL extension so everything runs on the WSL filesystem.

[shivsant]

Hi Team,
Will you be allowing workspace level settings to allow chat.pluginLocations?
Currently it is not allowed and I see this error in insiders as well -
"This setting can only be applied in user settings in local window or in remote settings in remote window."

Similar issues -
#307040
#303853

[canyonopm3026-create]

Regarding the question about workspace-level settings, I am also interested to know if chat.pluginLocations will be supported at the workspace level.

…

On Wed, Apr 8, 2026, 11:33 AM Shivsantosh Singh ***@***.***> wrote: *shivsant* left a comment (microsoft/vscode#307203) <#307203 (comment)> Hi Team, Will you be allowing workspace level settings to allow chat.pluginLocations? Currently it is not allowed and I see this error in insiders as well - "This setting can only be applied in user settings in local window or in remote settings in remote window." Similar issues - #307040 <#307040> #303853 <#303853> — Reply to this email directly, view it on GitHub <#307203 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7HYGQ67DNH34JE6RXG7L334UZ5NRAVCNFSM6AAAAACXJQOK7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMBXHA2DEOJSG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[shashik2]

I also need chat.pluginLocations at the workspace level.