[BUG] VSCode 2.1.139: acceptEdits / Edit automatically mode still prompts for Edit tool approval (regression persists since v2.1.79)

Resolved 💬 2 comments Opened May 12, 2026 by Rodsevich Closed Jun 15, 2026

Summary

The "Edit automatically" (acceptEdits) permission mode selected via the
VSCode extension dropdown is not honored at runtime. Every Edit /
Write tool call still triggers the "Make this edit to [file]?" prompt,
despite the status bar confirming the mode is active.

Only bypassPermissions bypasses the prompt reliably — acceptEdits does not.

Affected version

  • Extension: anthropic.claude-code v2.1.139 (darwin-arm64)
  • VSCode engine: ≥1.94.0
  • OS: macOS Darwin 25.3.0 (Apple Silicon)
  • Model: Opus 4.7

Regression history

The same bug has been reported and closed-as-duplicate multiple times since
v2.1.79 (2026-03-19):

  • #37518 (v2.1.78, macOS) — closed dup
  • #31827 (v2.1.71, macOS) — closed not-planned
  • #36348 (v2.1.79) — closed
  • #43283 (v2.1.91, Windows) — closed dup
  • #43953 (v2.1.92, root-cause analysis) — closed dup

60+ versions later in v2.1.139, the bug still reproduces. No canonical
open tracker exists, hence this fresh report.

Reproduction (100% reliable)

  1. ~/.claude/settings.json has "defaultMode": "default" (or any non-bypass value).
  2. Open the extension panel. Click the mode dropdown (bottom-right).
  3. Select "Edit automatically" — checkmark appears, status bar updates.
  4. Ask Claude to edit any file.
  5. Observed: "Make this edit to [file]?" approval dialog appears.
  6. Expected: Edit applied silently.
  7. Switch dropdown to "Bypass permissions" → same edit applied silently. ✅

No Edit(...) or Write(...) deny rule exists in any settings layer
(~/.claude/settings.json, workspace .claude/settings.json,
.claude/settings.local.json).

Suspected root cause (from closed dup #43953)

requestToolPermission in extension.js always forwards tool requests to the webview UI without checking the current permissionMode. The CLI is launched with the correct flags, but the extension layer ignores them when routing the prompt to the UI.

If accurate, the fix is a 1-line guard in requestToolPermission:
auto-resolve when permissionMode === 'acceptEdits' and the tool is
Edit / Write / NotebookEdit.

Impact

  • Defeats the purpose of acceptEdits for any non-trivial edit-heavy task.
  • Forces users into bypassPermissions (broader blast radius than intended)

as the only working auto-approve mode.

  • Breaks autonomous multi-agent / orchestrator workflows that rely on

acceptEdits semantics (write code but still confirm destructive bash).

Workarounds (none ideal)

| Workaround | Trade-off |
|---|---|
| bypassPermissions mode | Broader auto-approve than user wants |
| Downgrade to v2.1.78 | Loses 60+ versions of features/fixes |
| Edit(/path/**) allow rules | Affected by #15921, not reliable |

Ask

  • Confirm this is on the roadmap.
  • If a fix is already merged, indicate the target version.
  • If not, please reopen one of the closed canonicals or track here.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗