Globally configurable allowed tools #179

Yes it would be great, as it works for directories already to allow copilot to (permanently) add a directory it should be possible to allow it permanently to run a given tool!

It's hack time:

alias copilot="copilot --allow-tool 'shell(npm:*)' --allow-tool 'shell(go:*)' --allow-tool 'shell(git:diff:*)' --allow-tool 'shell(git:log:*)'"

+1. The per-launch --allow-tool flag and the per-location permissions-config.json both fall short for a common case: a self-hosted MCP server whose tools I trust in every repo.

With todays options I either:

• repeat --allow-tool 'my-mcp()' on every launch (only persists via a shell alias/wrapper), or
• duplicate the same tool_approvals block under each repo key in permissions-config.json (keyed by exact repo root, no wildcard, so it never covers a new repo).

A persisted, location-independent allow list would solve this. The existing --allow-tool grammar already expresses it cleanly, so the config could reuse it, e.g.:

// ~/.copilot/settings.json
{
  "permissions": {
    "allow": ["my-mcp()", "my-mcp(some_tool)", "shell(git:diff:*)"],
    "deny":  ["shell(curl:*)"]
  }
}

where my-mcp() = all tools of that MCP server (mirroring <mcp-server-name>(tool-name?) from copilot help permissions). Denials should keep precedence, as they do for the flags today.

I think the important part here is defining the permission lattice before adding another config surface.

A predictable precedence could be:

deny > repo deny > global deny > explicit session allow > repo allow > global allow > ask

Whatever ordering is chosen, it should be deterministic and visible through something like /permissions explain <tool-call>.

I would also normalize MCP permissions on stable (server, tool) identity rather than display name, so reconnects or renamed UI labels cannot change authority accidentally.

A small table-driven test covering conflicting global/repo/session rules would probably prevent a lot of future permission drift.