[BUG] VSCode extension: PowerShell permission prompt only shows Yes/No — missing "allow for session/project/always" options

[cveld]

Description

When Claude Code in the VSCode extension prompts for permission to run a PowerShell
command, the prompt only offers two options: Yes and No. The broader approval
options available in the CLI terminal — such as "Allow for this session",
"Allow for this project", or "Always allow" — are completely absent.

This makes it impossible to approve a class of PowerShell commands persistently
without manually editing settings files.

Steps to Reproduce

1. Open a project in VSCode with the Claude Code extension installed
2. Ask Claude to run any PowerShell command
3. Observe the permission prompt

Expected Behavior

The permission prompt should offer the same options as the CLI terminal:

• Yes (once)
• Yes, allow for this session
• Yes, allow for this project
• Yes, always allow
• No

Actual Behavior

The permission prompt only shows:

• Yes
• No

There is no way to approve a command more broadly than once from within the prompt itself.

Environment

• OS: Microsoft Windows 11 Enterprise 10.0.26200 Build 26200
• Claude Code VSCode extension version: 2.1.160
• VSCode version: 1.122.1 (x64)
• Shell: PowerShell 7.6.2 (pwsh)
• Claude Code CLI version: 2.1.158 (may not be used by the extension)

Impact

Every PowerShell command requires manual approval one by one. The only workaround
is to manually edit .claude/settings.local.json or ~/.claude/settings.json
with the appropriate allow rules — which is undiscoverable and error-prone.

Related Issues

• [FEATURE] Add "Yes, always allow" option to permission prompt that persists to global allowlist #32973 — Feature request for persistent "Always allow" from the prompt (CLI)
• [BUG] VSCode extension repeatedly asks for permission to edit the same file, even if Allow for this session is selected. #33047 — VSCode extension ignores "Allow for this session" (but at least shows
  the option)

[cveld]

Feature suggestion: granular command approval in the permission dialog

It would be great if the improved permission dialog also supported command-specific approval — not just blanket session/project/always options, but the ability to approve a specific command pattern directly from the dialog.

For example, when Claude wants to run Get-ChildItem -Path C:\work\git, the dialog could offer:

• Yes, once
• Yes, allow Get-ChildItem * for this session
• Yes, allow Get-ChildItem * for this project (saves to .claude/settings.local.json)
• Yes, always allow Get-ChildItem * (saves to ~/.claude/settings.json)
• No

This way users can incrementally build up a meaningful allowlist through normal usage, without needing to know the settings file format upfront. The command pattern shown could be editable so the user can broaden or narrow it before approving.

[github-actions]

Found 1 possible duplicate issue:

1. [BUG] "Edit/Write permission prompts in VS Code extension missing 'Always allow' option" #58830

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[cveld]

It seems #58830 surely is related, but not tied to PowerShell. In both cases Claude shows a permission dialog which can only be answered with yes/no. Ideally I expect some additional options such as session/project/always. Maybe the permission dialog must be refactored to allow for additional granularity.

[cveld]

Still experiencing this issue on v2.1.185, using the VS Code extension. The yes/no-only dialog isn't limited to PowerShell — it affects various tools. Recently it also shows up when Claude tries to read from the temp folder, where the only options are yes or no. As a workaround I've been adding broader permission allowlists in settings just to avoid the constant interruptions, which is not ideal from a security perspective.

The granular approve-once / session / project / always options would make a real difference here.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.