claude-code - 💡(How to fix) Fix [BUG] VSCode 2.1.139: acceptEdits / Edit automatically mode still prompts for Edit tool approval (regression persists since v2.1.79)

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)

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.