Skip to content

Feature: Per-tool 'always prompt' override (even with --allow-all) #1435

Description

@goergenj

Summary

Add a config.json setting (e.g., always_prompt_tools) that requires explicit user confirmation before a tool's first use in a session, even when running with --allow-all or --allow-all-tools.

This creates a middle ground between "allow" and "deny" — the tool is permitted, but always requires a one-time session consent before first invocation.

Motivation

Tools like WorkIQ (ask_work_iq) access sensitive organizational data — emails, meetings, Teams messages — via Microsoft 365 Copilot. Users may want --allow-all for file and shell operations but still require explicit consent before querying workplace data.

Today the only options are:

  • Allow all — no confirmation for any tool, including sensitive ones
  • Deny specific tools — blocks them entirely, which is too restrictive
  • Custom instructions — model-level guidance only; not enforceable and can be skipped

There is no way to say: "This tool is available, but always ask me before using it the first time."

Proposed Solution

A new always_prompt_tools array in ~/.copilot/config.json:

{
  "always_prompt_tools": ["ask_work_iq", "workiq-ask_work_iq"]
}

Behavior

  • Before the first call to a listed tool in a session, Copilot CLI displays a confirmation prompt
  • This overrides --allow-all, --allow-all-tools, and /allow-all
  • Once the user approves, subsequent calls to that tool in the same session proceed without re-prompting
  • If rejected, the tool is blocked for the rest of the session

Example UX

⚠️  WorkIQ (ask_work_iq) wants to access your Microsoft 365 data.
   This tool can read emails, meetings, Teams messages, and documents.
   
   Allow for this session? [y/N]

Use Cases

  1. Sensitive data tools — WorkIQ, M365 integrations, or custom MCP servers that access PII/corporate data
  2. Cost-bearing tools — Tools that consume API quota or trigger billing (e.g., paid external APIs)
  3. Irreversible actions — Tools that publish, deploy, or send communications
  4. Compliance — Organizations requiring audit-friendly consent for data access tools

Alternatives Considered

  • Custom instructions in copilot-instructions.md — Best-effort only; the model can skip them under heavy context or complex tasks. Not a security boundary.
  • --deny-tool — Too restrictive; blocks the tool entirely rather than gating it behind consent.
  • Per-call confirmation (no --allow-all) — Too noisy; users want frictionless file/shell ops but gated sensitive tools.

Relation to Existing Issues

This complements the permission system improvements in #307 and Epic #316. Specifically, it adds a consent tier between "allow" and "deny" that isn't covered by the existing --allow-tool / --deny-tool flags or the proposed permission profiles.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:permissionsTool approval, security boundaries, sandbox mode, and directory restrictions

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions