Feature: URL Permissions management in Settings

[faesel]

Summary

Add a URL Permissions section to the Settings page that lets users view and manage which external URLs/domains Copilot CLI can access without prompting.

Background

Copilot CLI controls which external URLs the agent can access. By default, all URLs require approval before access is granted. URL permissions apply to the web_fetch tool and network-accessing shell commands (curl, wget, fetch).

Permissions can be persisted per session or permanently, stored in ~/.copilot/permissions-config.json.

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

CLI flags for context

• --allow-all-urls — disables URL verification entirely
• --allow-url=DOMAIN — pre-approves a specific domain
• --deny-url=DOMAIN — denies a specific domain

Limitations (from docs)

• URLs in file contents, config files, or env vars read by commands are not detected
• Obfuscated URLs may not be detected
• HTTP and HTTPS are treated as different protocols and require separate approval

Proposal

Settings page section

Add a URL Permissions panel in the Settings page that:

• Reads allowed/denied URLs from permissions-config.json
• Displays allowed domains with protocol (http/https distinction)
• Displays denied domains (if any)
• Allows users to add new allowed domains (text input with validation)
• Allows users to remove individual URL permissions
• Groups by project path if permissions are project-scoped

IPC surface

• urls:get-permissions — reads URL permissions from permissions-config.json
• urls:allow-url(projectPath, domain) — adds a domain to the allowed list
• urls:deny-url(projectPath, domain) — adds a domain to the denied list
• urls:remove-permission(projectPath, domain) — removes a URL permission entry

Security considerations

• Validate domain format (no paths, no protocols in input — handle protocol separately)
• Warn users that allowing a domain permits all subpaths on that domain
• Display HTTP vs HTTPS as separate entries (matching CLI behaviour)
• Prototype pollution guards on project path keys

UX considerations

• Input field with protocol selector dropdown (http/https/both)
• Visual distinction between allowed (cyan) and denied (orange) domains
• Empty state message explaining what URL permissions do
• Tooltip on each entry explaining the scope of the permission

Investigation needed

• Determine the exact JSON structure for URL permissions in permissions-config.json
• Check whether URL permissions are per-project or global
• Verify whether wildcard/subdomain matching is supported

[faesel]

This is in a similar space to tools whitelisting, there doesnt seem to be a file driven approach to enabling/disabling URLs