Add path prefixes to file and web permissions

Describe the feature or problem you'd like to solve

Address noisy folders and generic domains using more granular permissions

Proposed solution

To allow GHCP CLI users to avoid context noise, excess file rehydration, and overly broad web permissions, I propose adding folder fragments to permission rules and prompts.

Web Permissions: In addition to domain-based grants like raw.githubusercontent.com, also offer more restrictive grants like raw.githubusercontent.com/org/project/* and raw.githubusercontent.com/org/project/key/reference/header.h.

Benefits:

• Principle of Least Privilege - agent can only access specific areas of multipurpose sites
• Observability/Supervision - new grant requests help key the user into shifts in the agent's operations

File Permissions: In addition to folder-based grants like ~\OneDrive\Documents, also offer per-file grants like ~\OneDrive\Documents\my-awesome-spec.md.

Benefits:

• Certain folders may contain noise like related draft content or large amounts of unrelated content, so this would save the agent time and confusion needlessly exploring that.
• Cloud storage folders may contain large numbers of dehydrated files or large dehydrated files, so the agent's eager accessing of these adjacent files would trigger prohibitive bandwidth, time, and disk costs.

Alternatives

The copilot help permissions docs suggest this is already in the works, so I wanted to provide specific feedback about this approach. That said, I could think of a few alternate approaches to each of these issues:

1. Specific MCPs per multipurpose site (like the GH MCP) could offer local cloning and searching of a repo when it detects repeated allowed grants.
2. For file accesses, repeated accesses+grants could trigger an offer to copy the file into the workspace for repeated use. The file may fall out of sync with the original, but the snapshot is likely good enough and could be validated periodically.
3. Dehydrated (OneDrive, Dropbox, etc.) files can be detected, at least on Windows, and so could trigger different behavior like a "read but not hydrate" or "can I hydrate" folder permission or a warning. (This would not address the noise issue, only the hydration problem.)

Example prompts or workflows

1. A subagent is reading source from an interesting repo, so it asks to pull many related URLs like https://raw.githubusercontent.com/org/project/branch/path/to/file.cpp. Instead of manually approving grants for every touch because I don't want to allow literally anything from GitHub by allowing raw.githubusercontent.com, I could allow raw.githubusercontent.com/org/project/branch/ for the session or even permanently.
2. I give an agent a document from a very noisy folder (lots of related unreliable/draft content and unrelated content) as context for my current session. Instead of approving a manual grant for every touch because allowing folder access would confuse the agent, I grant persistent access to the file.
3. Similar to the noisy folder case, but allowing the folder would instead trigger hydration of a dehydrated (e.g. OneDrive, Dropbox, etc.) folder. I would instead grant persistent access to the file.

Additional context

No response

Commencez par le point d’entrée copilot help permissions et suivez la manière dont les autorisations accordées pour les fichiers et le Web sont représentées et demandées. Définissez les règles de correspondance de chemins prises en charge pour les URL et les fichiers, y compris les autorisations accordées pour la session et les autorisations persistantes, puis vérifiez que les invites et les contrôles d’accès appliquent les portées plus étroites décrites dans les exemples.