Add option to disable persistent "Always Allow" approvals (force per-action confirmation)

[willheisenberg]

What would you like to be added?

Description

Hi 👋

First of all, thank you for building and maintaining this extension — it's a great tool and already very useful in daily workflows.

I would like to request a feature (or configuration option) to disable persistent approvals, specifically the behavior behind the "Always allow" option.

Why is this needed?

Problem

Currently, when selecting "Always allow" for an action (e.g. file edits), the decision is persisted (likely via workspace/global state).
This leads to the following behavior:

• The extension stops asking for confirmation for subsequent actions

• User-level settings such as:

  • qwen.approvalMode = "default"
  • qwen.confirmFileEdits = true

  are effectively bypassed after that point

This creates a mismatch between:

• configured intent (always ask) and
• runtime behavior (auto-approve after one click)

Additional context

Why this is problematic

From a safety and control perspective:

• Users may accidentally grant broader permissions than intended

• There is no obvious way to revert this behavior except:

  • resetting sessions
  • clearing storage manually

• This is especially problematic in:

  • production environments
  • devcontainers
  • multi-repo workflows

---

Feature Request

Introduce a configuration option to disable persistent approvals entirely, for example:

{
  "qwen.disablePersistentApprovals": true
}

or:

{
  "qwen.approvalPersistence": "session" // or "none"
}

---

Expected Behavior

When enabled:

• The extension should always prompt for confirmation, regardless of previous "Always allow" selections
• No approval decisions should be persisted across actions
• Behavior should be deterministic and aligned with user configuration

---

Optional Enhancements

• Add a UI toggle:
  "Disable 'Always allow' (always ask per action)"

• Allow scoping:

  • per workspace
  • per tool (edit, shell, etc.)

---

Additional Context

This would bring the extension more in line with policy-based permission systems, similar to tools like OpenCode, where:

• permissions are declarative
• behavior is predictable
• no hidden state overrides configuration

---

Summary

This feature would:

• improve safety
• reduce confusion
• give advanced users more control
• align runtime behavior with configuration

---

Thanks for considering this! 🚀

[LaZzyMan]

@willheisenberg this work may help you #2283 , It will be available in the next version.

[willheisenberg]

Thanks a lot for this work — the new permission system looks like a huge improvement 👍
Especially moving from implicit state to explicit, rule-based configuration is exactly the right direction.

I have one small UX suggestion related to this (based on how the new system is described):

With rules like:

{
  "permissions": {
    "ask": ["*"]
  }
}

it seems that “Always allow” will effectively have no impact, because ask has higher priority than allow.

From a user perspective, this could be confusing:

• The UI still offers “Always allow”
• But the action will continue to require confirmation due to policy
• The user may not understand why their choice is not respected

👉 It might be helpful to:

• Disable or hide the “Always allow” option when it would be overridden by existing rules, or
• Show a small hint like:
  “This action is still controlled by your permission rules”

This would make the system feel more predictable and aligned with the new policy-based model.

Thanks again — really looking forward to this feature landing 🚀

[LaZzyMan]

@willheisenberg You are absolutely right. We have implemented this design; when the tool invokes the ask permission to access user-configured permissions, the Always Allow option will not be displayed. Thank you for your suggestion.