[FEATURE] Expose bypass permissions in the VS Code extension via a per-session, type-to-confirm gate

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Problem

Today, the only reliable way to run the VS Code extension in bypass-permissions mode is to launch claude --dangerously-skip-permissions in the integrated terminal — i.e. outside the extension's own UI. The extension cannot pass startup parameters, and claudeCode.initialPermissionMode: "bypassPermissions" / settings.json defaultMode either don't expose the mode in the picker or are reported as unreliable (see #12604, #36348, #35756).

The CLI-only situation is understandable if the concern is a persistent toggle: a checkbox that stays on across every project and session is easy to enable once and forget, which is dangerous because bypass mode lets the agent run arbitrary commands with no prompt — including actions triggered by prompt-injection content inside a project. But that concern is about persistence, not about the mode itself.

Proposed Solution

Proposed solution

Expose bypass mode in the extension UI while keeping the safety properties of the CLI flag, by making it explicit and per-session, never a silent persistent default:

1. Selecting "Bypass permissions" from the mode picker opens a type-to-confirm dialog — the user must type an exact phrase (e.g. yes, enable it) into a textbox; a plain "OK" button is not enough. This mirrors GitHub's own "type the repo name to delete" pattern.
2. The confirmation is scoped to the current session/window only. It does not persist and cannot be set as a saved default from the UI. Reopening the workspace starts from the normal default mode again.
3. A visible, persistent indicator (e.g. the red mode indicator) stays on for the whole session so the elevated state is never invisible.
4. Optionally keep it behind an org-level kill switch (permissions.disableBypassPermissionsMode / managed settings) so enterprises can still disable it entirely.

Why this is safe enough

• The friction is deliberate and human: typing an explicit phrase can't be triggered by an accidental click or by automation as easily as a button press.
• No persistence means you can't leave it on and forget — the worst case is one session, not "every session forever".
• It gives users the ergonomics they keep asking for (staying inside the extension UI) without weakening the default-safe posture for everyone else.

Alternative Solutions

Simply re-adding the dropdown entry (as in #16042) — rejected before, presumably because it normalizes a persistent bypass. The type-to-confirm + per-session scoping is meant to answer that objection directly.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

As a Windows developer, I work with Claude inside the VS Code extension because I prefer having the console integrated in my editor rather than a separate terminal window.

A typical scenario:

1. I ask Claude to perform a multi-step task (e.g. build, run scripts, inspect output) that requires it to run many different PowerShell commands.
2. Because the commands differ from one another — and any command that merely contains something like cd is treated as a new command needing approval — the extension prompts me to authorize each one individually.
3. There is no way to pass startup parameters from the extension (see #16042), so I cannot pre-approve the batch the way claude --dangerously-skip-permissions would from the CLI.
4. The result is that I have to sit at the keyboard for hours clicking "approve" on every single command, which defeats the purpose of delegating the task.

The obvious workaround — running claude --dangerously-skip-permissions in a plain terminal — forces me out of the integrated editor experience I chose the extension for in the first place. A per-session, type-to-confirm bypass in the extension UI would let me opt into an unattended run explicitly, once, and then let Claude work through the whole sequence without babysitting.

Additional Context

Context / related issues

• #16042 — requested adding bypassPermissions to the VS Code extension mode dropdown; closed as not planned. This is the closest prior request and the one this proposal tries to move past. A comment there also notes the core limitation: the VS Code extension cannot specify startup parameters, so there is no way to pass --dangerously-skip-permissions from the extension itself.
• #25503 — related but about the CLI flag and its per-launch dialog, not the extension UI.
• #39523 — meta issue tracking the broader breakage of bypass mode.

This is specifically about the VS Code extension UI. It tries to address the safety concern that presumably motivated the not planned decision on #16042, rather than just re-requesting the dropdown entry.