Support repository-level, version-controlled command permissions (allow / ask / deny) #5297

Describe the feature or problem you'd like to solve

While preparing a developer workshop, I wanted to commit a shared set of Copilot CLI command permissions alongside the repository's instructions, skills, and agents. Everyone cloning the repository should be able to review and adopt the same defaults, without individually configuring their home directory, repeatedly approving identical commands, or copying CLI flags.

The missing capability is repository-level, version-controlled allow / ask / deny rules for commands, not just saving one user's approvals for a project on their own machine.

Copilot CLI already supports .github/copilot/settings.json, but the documented repository settings do not include command permission rules. Saved project permissions under ~/.copilot/permissions-config.json are local to each user, rather than a portable configuration shared through the repository.

Proposed solution

Support a committed repository permission configuration, ideally by extending .github/copilot/settings.json, with:

• Allow: preapprove specific commands or command patterns without repeated prompts.
• Ask: require explicit approval for matching commands, even when a broader allow rule matches.
• Deny: block matching commands, with deny taking precedence over ask and allow.

Reuse Copilot CLI's existing permission pattern syntax where practical, and document matching and precedence. Rules should be repository-scoped and portable across collaborators' machines.

Repository-provided approvals should require explicit user review and opt-in, not silently apply just because a repository was cloned. Changes that expand approvals should be surfaced for review. Repository rules must not weaken organization restrictions or explicit user deny rules.

Named or switchable permission profiles are not required for this use case: a committed, team-shared permission file would be sufficient.

Example prompts or workflows

1. Workshop setup: the organizer commits approvals for the workshop's test and lint commands. Participants review and accept those rules instead of configuring identical permissions individually.
2. Team onboarding: new contributors clone the repository and can adopt the same reviewed command defaults as the rest of the team.
3. Team standards: setting up team standards for permissions corresponding to committed instruction files and skills would allow better collaboration.
4. Mixed approval levels: allow npm run test and npm run lint, ask before git push, and deny git reset --hard.
5. Reviewable permission changes: a pull request adds a new command approval alongside the script or workflow that needs it.

This avoids requiring broad --allow-all access simply to reduce repetitive approvals.

Additional context

Claude Code supports repository-level .claude/settings.json files with permissions.allow, permissions.ask, and permissions.deny. I would like an equivalent native Copilot CLI capability.

Related issues:

• Permission Profiles: named, switchable permission presets (global + per-repo) #3176 proposes a broader system of named, switchable permission profiles, including per-repository profiles. This request focuses specifically on committed, team-shared rules without requiring a profile system.
• Support a default config file for permissions #2398 requests a default permission configuration file, primarily at the user level.
• Remember permission approvals across sessions #5083 requests remembering approvals across sessions.
• Permissions from .claude/settings.json not taken into account (also in v1.0.12!) #2338 reports that permissions in .claude/settings.json are not applied.