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:
- Specific MCPs per multipurpose site (like the GH MCP) could offer local cloning and searching of a repo when it detects repeated allowed grants.
- 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.
- 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
- 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.
- 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.
- 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
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 likeraw.githubusercontent.com/org/project/*andraw.githubusercontent.com/org/project/key/reference/header.h.Benefits:
File Permissions: In addition to folder-based grants like
~\OneDrive\Documents, also offer per-file grants like~\OneDrive\Documents\my-awesome-spec.md.Benefits:
Alternatives
The
copilot help permissionsdocs 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:Example prompts or workflows
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 allowingraw.githubusercontent.com, I could allowraw.githubusercontent.com/org/project/branch/for the session or even permanently.Additional context
No response