[FEATURE] expose setPermissionMode as a public VS Code command

Resolved 💬 1 comment Opened May 1, 2026 by Appdev-guard Closed Jun 1, 2026

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

Hello.

I'm building a desktop overlay (Orchestr) that surfaces every AI coding session across IDEs in a single notch-style island. Users can see all their active Claude Code conversations at a glance, including their per-session permission mode (Ask / Edit Automatically / Plan / Auto / Bypass).

The natural next step is to let users SWITCH a session's permission mode directly from the overlay — same way they would by pressing Shift+Tab in the IDE. But there is no clean way to do this from outside the Claude Code VS Code extension today:

  • Third-party extensions cannot webview.postMessage() into a webview they did not create (correct VS Code security behaviour).
  • No public VS Code command exists for setting the mode (only claude-vscode.focus, blur, acceptProposedDiff, newConversation, etc.).
  • The Bridge / Remote Control feature requires per-session manual opt-in and external auth — wrong shape for a passive overlay.

So today the overlay can DISPLAY the current mode (read from the JSONL transcript) but cannot CHANGE it without resorting to fragile keystroke injection, which I tested and abandoned because it polluted users' chat input when timing slipped.

💕

Proposed Solution

Add a public VS Code command:

claude-vscode.setPermissionMode(mode: string, channelId?: string)

where mode is one of: "default" | "acceptEdits" | "plan" | "auto" | "bypassPermissions".

Optional second command for the effort/thinking level slider:

claude-vscode.setThinkingLevel(level: "low" | "medium" | "high" | "max", channelId?: string)

Both should reuse the existing internal routing, just exposed as vscode.commands.registerCommand so any other extension can call:

vscode.commands.executeCommand("claude-vscode.setPermissionMode", "plan");

The mode flips live, exactly as if the user had used Shift+Tab. Validation, persistence, response shape — all already handled inside the extension.

Alternative Solutions

  • webview.postMessage from external extensions: blocked by VS Code's security model (correctly).
  • Keystroke injection (Shift+Tab + arrows + Enter via SendInput on Windows): tried it. Off-by-N navigation drift because timing of the menu open/close races with arrow events. Worse: when the menu does not open, the trailing Enter submits whatever sits in the chat input, causing accidental prompts. Not safe to ship.
  • Bridge / Remote Control feature: works but requires manual per-session toggle + external auth — wrong shape for a passive overlay tool.
  • Writing to settings.json's claudeCode.permissionMode: only affects NEW conversations per the docs.

Priority

High - Significant impact on productivity

Feature Category

Developer tools/SDK

Use Case Example

Concrete scenario:

  1. I'm working on a Next.js project. My Claude Code session in VS Code is in bypassPermissions mode because I trust my own commands.
  2. I switch to a more sensitive file (say, .env.production or a deploy script) and want Claude to ASK before each edit while I review changes manually.
  3. Instead of leaving the keyboard, focusing the IDE, pressing Shift+Tab, navigating the menu, pressing Enter, then returning to my overlay — I just click "Ask before edits" on the session's chip in the Orchestr island. The chip flips, and Claude in the IDE switches mode in the same instant.
  4. Two seconds saved per switch × dozens of switches per day = real ergonomic gain. More importantly, it removes the friction that today makes users stay in bypassPermissions even when they should not, because switching back and forth is annoying.

This is exactly the workflow Anthropic enables when keeping the Shift+Tab UX inside the extension. A public command lets external tools mirror it without touching the chat input or risking unsafe key injection.

Additional Context

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗