Feature: Allowed Tools management in Settings

[faesel]

Summary

Add a Allowed Tools section to the Settings page that lets users view and manage which tools Copilot CLI can use without prompting.

Background

Copilot CLI stores tool permission decisions in ~/.copilot/permissions-config.json, organised by project location. When a user approves a tool (e.g. shell(rm), write, or an MCP server tool), the CLI records it so they are not prompted again in that project.

Reference: https://docs.github.com/en/copilot/how-tos/copilot-cli/set-up-copilot-cli/configure-copilot-cli#setting-allowed-tools

Tool specification format

• Shell commands: shell(COMMAND) e.g. shell(rm), shell(git push)
• Write tools: write
• MCP server tools: MCP_SERVER_NAME(tool_name) or just MCP_SERVER_NAME for all tools

Proposal

Settings page section

Add a Allowed Tools panel in the Settings page that:

• Reads ~/.copilot/permissions-config.json and displays allowed/denied tools per project
• Allows users to remove individual tool permissions (reset to "ask again")
• Allows users to add new allowed tools (with appropriate input validation)
• Groups permissions by project path for clarity
• Shows tool type (shell/write/MCP) with distinct styling

Session page integration

In the Sessions page where toolsUsed are already displayed:

• Add a clickable action to each tool badge that adds it to the allowed tools list
• Show a confirmation dialog before whitelisting (make it obvious the user is permanently allowing a tool)
• Change the background colour of tool badges that are already in the allowed list (e.g. subtle cyan tint vs default border-only)
• Include a tooltip explaining what "allowed" means in this context

IPC surface

• tools:get-permissions — reads permissions-config.json, returns structured permissions per project
• tools:allow-tool(projectPath, toolSpec) — adds a tool to the allowed list for a project
• tools:remove-tool(projectPath, toolSpec) — removes a tool from the allowed list
• tools:is-allowed(projectPath, toolSpec) — checks if a specific tool is allowed (for badge colouring)

Security considerations

• Validate tool specification format before writing
• Warn users clearly that allowing shell without arguments permits ANY shell command
• Prototype pollution guards on project path keys
• Path traversal protection on project paths

UX considerations

• Tool badges in sessions should have a clear visual distinction between "used" and "used + allowed"
• The confirmation dialog should explain: "This will allow Copilot to use this tool in future sessions without asking. Are you sure?"
• Consider an "undo" mechanism (toast notification with undo button after allowing)

Investigation needed

• Determine the exact JSON structure of permissions-config.json (approve a tool in CLI to generate the file)
• Check whether permissions are per-project or global
• Verify whether modifications to this file are respected by a running CLI session or only on next launch

[faesel]

This still seems to be a feature thats not supported by copilot yet, there are some suggestions of using a permissions-config.json file. Although using the allow-tool command copilot --allow-tool='grep', doesnt seem to populate any file within the copilot folders. I think its just held in memory for the running session not sure how the user generated a permissions file.

Related issue:
github/copilot-cli#1973