Skip to content

Feature Request: Tool whitelist for Interactive Mode #1973

Open
Feature
Open
Feature Request: Tool whitelist for Interactive Mode#1973
Feature
Labels
area:configurationConfig files, instruction files, settings, and environment variablesarea:permissionsTool approval, security boundaries, sandbox mode, and directory restrictions

Description

@Dicer-J
Dicer-J
opened on Mar 11, 2026

Describe the feature or problem you'd like to solve

Currently Interactive mode requires manual approval for every tool call, including safe read-only operations (grep, cat, find, git log, git status, etc.). The only alternative is /allow-all which also approves destructive operations.

Proposed solution

Add a persistent allowed_tools whitelist in ~/.copilot/config.json, similar to how antigravity handles tool permissions. Users can pre-approve safe, non-modifying
commands and only be prompted for dangerous operations (file writes, deletes, shell commands that modify state).

Example prompts or workflows

{
"allowed_tools": ["bash:grep", "bash:find", "bash:cat", "bash:git log", "bash:git status", "view", "glob"]
}

Additional context

No response

Activity

  1. Dicer-J
    added the
    Feature
    issue type on Mar 11, 2026
  2. Dicer-J
    added
    triage
    on Mar 11, 2026

  3. DanteDeRuwe commented on Mar 11, 2026

    @DanteDeRuwe
    DanteDeRuwe
    on Mar 11, 2026

    Right now I have set a command alias to be able to whitelist tools like so:

    alias ghc="copilot \
	--allow-tool='write' \
	--allow-tool='shell(git log)' \
	--allow-tool='shell(git status)' \
	--allow-tool='shell(echo)' \
	--allow-tool='shell(grep)' \
	--allow-tool='shell(find)' \
	--allow-tool='shell(ls)' \
	--allow-tool='shell(cat)' \
	--allow-tool='shell(head)' \
	--allow-tool='shell(tail)' \
	--allow-tool='shell(sed)' \
	--allow-tool='shell(awk)' \
	--allow-tool='shell(sort)' \
	--allow-tool='shell(uniq)' \
	--allow-tool='shell(wc)' \
	--allow-tool='shell(jq)' \
        ...

    Would indeed be great if this can be configured with a config file, just like this is done in vscode by using chat.tools.terminal.autoApprove setup (vscode even supports regex patterns)

    In general, configuring --allow-tool, --deny-tool, --available-tools, etc via either global or per-repo config would be great.

  4. ssbarnea commented on Mar 15, 2026

    @ssbarnea
    ssbarnea
    on Mar 15, 2026

    I had to google a lot to find-out that was never implemented, back to Claude.

  5. DanteDeRuwe commented on Mar 24, 2026

    @DanteDeRuwe
    DanteDeRuwe
    on Mar 24, 2026

    Any updates on this?

  6. DanteDeRuwe commented on Mar 27, 2026

    @DanteDeRuwe
    DanteDeRuwe
    on Mar 27, 2026

    v1.0.12 just arrived and the release notes say:

    Read .claude/settings.json and .claude/settings.local.json as additional repo config sources

    So I was full of hope that we could define our permissions there (until copilot adds their own settings/config file).

    Too bad it does not work properly. I logged bug #2338. Maybe soon...

  7. jovere commented on Apr 1, 2026

    @jovere
    jovere
    on Apr 1, 2026

    Please add this! The incessant nagging for simple things like grep is dangerous, as it's making me want to just /yolo. Claude has had this feature for half a year!

  8. schizek commented on Apr 10, 2026

    @schizek
    schizek
    on Apr 10, 2026

    Agree... this is crucial. I avoid using Copilot CLI whenever possible because Warp and Claude have much better experiences and are a lot less clunky. This missing feature is # 1 on my list.

  9. czf commented on Apr 14, 2026

    @czf
    czf
    on Apr 14, 2026

    Would also like to see this as an option in config.json

  10. examon
    added
    area:permissionsTool approval, security boundaries, sandbox mode, and directory restrictions
    area:configurationConfig files, instruction files, settings, and environment variables
    and removed
    triage
    on Apr 16, 2026

  11. DanteDeRuwe commented on Apr 28, 2026

    @DanteDeRuwe
    DanteDeRuwe
    on Apr 28, 2026

    User settings are now stored in ~/.copilot/settings.json, separate from internal state in config.json

    settings.json seems like the ideal place for the whitelist and/or blacklist now.

    EDIT: just noticed the permissions-config.json file that is used now for per-project permissions. Step in the right direction, but would be amazing if this could also accomodate global permissions

  12. yionis01 commented on Apr 30, 2026

    @yionis01
    yionis01
    on Apr 30, 2026

    same need here. please allow persistent configuration of allow and deny tools. it's super tedious to reapprove every time. there are read only tools that i want to always allow but still get prompted for other tools, not a binary all or nothing.

  13. DanteDeRuwe commented on Jun 17, 2026

    @DanteDeRuwe
    DanteDeRuwe
    on Jun 17, 2026

    It's kind of ridiculous now that this is not supported yet. And "just use auto mode" does not follow principle of least privilege for me

  14. joegas commented on Aug 24, 2026

    @joegas
    joegas
    on Aug 24, 2026

    This is my biggest source of frustration. In Claude Code, I can specify the depth of the permission. Here, only the first subcommand can be whitelisted. For glab, that is fatal, because i give permisison for e.g. creating issues, although i only need to give the agent read-access:

    Image

  15. Jerry10Mx commented on Aug 24, 2026

    @Jerry10Mx
    Jerry10Mx
    on Aug 24, 2026 via email

  16. kvnloo commented on Sep 27, 2026

    @kvnloo
    kvnloo
    on Sep 27, 2026

    There is a second issue here beyond persistence: command permissions need to match the actual command shape, not just the first executable/subcommand.

    For example, approving read-only glab issue view should not implicitly authorize glab issue create. Same for git status vs git push.

    I would make shell permission matching operate on normalized argv/prefix rules and test at least:

    • exact command
    • argument prefix
    • shell operators/pipes
    • quoted arguments
    • aliases/wrappers
    • deny overriding a broader allow

    That lets users safely remove approval fatigue without pushing them toward /allow-all.

  17. DanteDeRuwe commented on Sep 30, 2026

    @DanteDeRuwe
    DanteDeRuwe
    on Sep 30, 2026

    FYI: I talked to Steve Sanderson in person at NDC Oslo and he told me tool whitelists at a user level are not where he sees Copilot going moving forward. He suggested instead to use assisted tool permissions using /allow-all auto (also configurable by default within /config). This sends the requested tool to a separate LLM to judge whether or not tool usage is permitted. That, along with sandboxing, is more aligned to the Copilot teams vision for approvals.

  18. Tak2121 commented on Sep 30, 2026

    @Tak2121
    Tak2121
    on Sep 30, 2026 via email

  19. Tak2121 commented on Sep 30, 2026

    @Tak2121
    Tak2121
    on Sep 30, 2026 via email
  20. patniko
    marked It should be possible to configure a set of commands the agent can run without permission #2484 as a duplicate of this issue on Oct 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:configurationConfig files, instruction files, settings, and environment variablesarea:permissionsTool approval, security boundaries, sandbox mode, and directory restrictions

    Type

    Feature

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions