[BUG] Desktop: "Disable automatic verification" does not persist, and a hand-written autoVerify: false in .claude/launch.json is overwritten with true shortly after app start

Status Open
Reported on v2.1.227
Maintainer reply None cached
Activity 3 comments · opened Aug 13, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

The documentation gives two ways to turn auto-verify off. Neither holds.

Auto-verify is on by default. Disable it per-project by adding "autoVerify": false to .claude/launch.json, or toggle it from the server dropdown menu. — https://code.claude.com/docs/en/desktop#auto-verify-changes
  1. The menu toggle does not persist. In the Browser pane's Panel settings (the ⋮ button), the item "Disable automatic verification" can be toggled, but reopening the menu shows the default again.
  1. A hand-written "autoVerify": false is overwritten. The app replaces it with "autoVerify": true about half a minute after start. Across a whole session, every value the app itself wrote was true; the only times the file ever held false were when it was written by hand.
  1. The menu and the file contradict each other. Observed at the same moment: the menu showed "Disable automatic verification" checked (auto-verify disabled) while .claude/launch.json held "autoVerify": true (auto-verify enabled).

The UI is German here; the item reads "Automatische Verifizierung deaktivieren".

What Should Happen?

  1. Toggling the menu item persists across reopening the menu and across restarts.
  2. A hand-written "autoVerify": false in .claude/launch.json is honoured and not overwritten, as the documentation states.
  3. The menu state and the file contents agree with each other.

Error Messages/Logs

No error is surfaced. The evidence is the file being rewritten.

`.claude/launch.json` did not exist in this project before; it was created by hand:

    {
      "version": "0.0.1",
      "autoVerify": false,
      "configurations": []
    }

The file is 72 bytes with `false` and 71 bytes with `true`, so the byte size alone identifies the value.

    13:55:43   file written by hand, autoVerify: false          72 B
    14:13:28   app process start (full restart, all processes ended first)
    14:14:00   file replaced by the app, autoVerify: true       71 B   <- 32 s after start
    14:23:51   replaced again, autoVerify: true                 71 B
    14:27:24   replaced again, autoVerify: true                 71 B

After the rewrite the file's creation time equals its last-write time, so the file is
replaced wholesale (write-temp-and-rename), not edited in place.

An earlier run showed the same with the app already running: a hand-written `false` at
13:54:0x was overwritten with `true` at 13:54:22.

Searched for any stored record of this toggle and found none:

    %APPDATA%\Claude   (recursive, every file < 20 MB)   no key for auto-verify
    %LOCALAPPDATA%\Claude                                no match
    ~\.claude                                            only inside conversation .jsonl transcripts

`claude_desktop_config.json` has keys for neighbouring preview state
(`launchPreviewPersistedWorkspaces`, `launchPreviewSessionScopedSessions`,
`launchPreviewAllowedOrigins`) but no key for auto-verify. The neighbouring
"Persist sessions" toggle in the same menu does have a slot there; this one does not.

Steps to Reproduce

The app is packaged as MSIX. Note that writes to %APPDATA% are redirected: from inside the
app the config appears under %APPDATA%\Claude\, while from an ordinary shell it exists only
under %LOCALAPPDATA%\Packages\<package family>\LocalCache\Roaming\Claude\. Both are the same
file. This matters when checking the file from a terminal.

Route A — the menu toggle

  1. Open a local session on a project folder and open the Browser pane.
  2. Open Panel settings (the ⋮ button in the Browser pane's title bar). The menu reads:

Datei öffnen (Open file)
Screenshot speichern (Save screenshot)
Erlaubte Websites verwalten (Manage allowed sites)
------------------------------------------
Links im Browser-Panel öffnen (Open links in the Browser pane)
Automatische Verifizierung deaktivieren v (Disable automatic verification)
Sitzungen beibehalten Nicht behalten > (Persist sessions)

  1. Toggle "Disable automatic verification".
  2. Close the menu and reopen it. The state is back to the default.

Note: "Manage allowed sites" contains no checkbox for this; the toggle exists only here.

Route B — the documented file

  1. Quit the app completely (end all processes, not just the window).
  2. Create .claude/launch.json in the project folder with:

{
"version": "0.0.1",
"autoVerify": false,
"configurations": []
}

  1. Start the app and open that project.
  2. Watch the file. Within about 30 seconds it is replaced with "autoVerify": true.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.227

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment

Claude Desktop 1.28929.0 (MSIX package) — newest release at the time of filing,
changelog entry dated 2026-08-11
OS Windows 10, 10.0.19044
Session local; project folder on a mapped network drive (X: -> \\fileserver\share)
Permission mode auto (per-folder, stored in epitaxy-folder-permission-mode)
Preview servers none configured and none running (preview_list returns []);
the Browser pane was opened with preview_start {url}
UI language German — labels above are quoted verbatim with an English translation

Possibly related

The changelog for 1.28929.0 — the version in use here — contains this line:

Fixed some Windows installs (MSIX packages and enterprise-managed roaming profiles) failing to save chat history, settings, and scheduled tasks, and Cowork failing to start with "Download failed" after an app update.

This install is an MSIX package, and the symptom here is a setting that fails to save. So
either that fix does not cover this setting, or autoVerify takes a different path than the
settings it addressed. That seems worth checking first.

An earlier release (v1.24012.0, 2026-07-21) notes:

Fixed the app freezing when Claude Code updated its configuration file during concurrent use

so the app and Claude Code writing the same configuration concurrently has a history in this area.

#86175 (open) reports that preview_start prompts in every permission mode since desktop
1.28929.0 — the same version — and describes approvals living in an in-memory Set keyed by
session with nothing written to disk, with no settings key able to make them permanent. That
is a different code path (spawn consent, not auto-verify), but the "state is in memory only"
pattern matches what is measured above.

Host names and paths in this report are placeholders; the real ones differ but have the same shape.

View original on GitHub ↗

3 Comments

level420 · 2 months ago

Re-tested on Claude Desktop 1.30096.1 (changelog entry dated 2026-08-13; nothing in it
addresses this). Claude Code is now 2.1.229. Environment otherwise unchanged: Windows, MSIX
package, permission mode Auto, no preview servers configured.

Polarity used throughout, since the wording invites confusion: the menu item reads "Disable
automatic verification", so a checkmark means auto-verify is off, which corresponds to
"autoVerify": false in the file.

The re-test narrows this down considerably. The file is honoured at startup; it is the
runtime path that goes wrong.

Startup path — works

10:12:21 set by hand to autoVerify: false, app closed 72 bytes
10:12:30 app started
10:15:49 file still 72 bytes, autoVerify: false untouched for 199 s

The Panel settings menu then showed "Automatische Verifizierung deaktivieren"
("Disable automatic verification") checked — matching the file.

This is the first time the menu and the file agreed. So the app does read
.claude/launch.json at startup and does honour autoVerify: false.

Runtime path — still wrong

09:32:15 set by hand to autoVerify: false, app running 72 bytes
09:32:42 rewritten by the app to autoVerify: true 71 bytes <- 28 s later,
no interaction

09:35:31 "Automatische Verifizierung deaktivieren" ticked in the menu
-> the app wrote the file again, and the result was still autoVerify: true

So a value set while the app is running is discarded, and a click on the menu item produces a
write that ends up as true — the opposite of what the item says. The menu also still does not
keep its checkmark when toggled during a session.

Under 1.28929.0 the startup path failed as well: a hand-written false was overwritten about 32
seconds after start. That part appears to be fixed in 1.30096.1; the runtime path is not.

What this means in practice

There is now a workaround: quit the app completely, set "autoVerify": false in
.claude/launch.json, then start the app. That sticks. The documentation does not mention that
the app must be closed, and the menu route remains unusable.

level420 · 1 month ago

Zweiter Nachtrag zu #86383 — zum Einfügen als Kommentar

Der Kasten unten ist der Kommentartext. Die äußeren Zäune aus vier Rückstrichen bleiben draußen.

````
Re-tested on Claude Desktop 1.37937.1 (last version tested before: 1.30096.5). Claude Code
2.1.246. Environment otherwise unchanged: Windows, MSIX package, permission mode Auto.

Polarity, since the wording invites confusion: the item reads "Disable automatic verification",
so a checkmark means auto-verify is off, which corresponds to "autoVerify": false.

Fixed: the file is no longer overwritten

A hand-written value now survives while the app is running.

08:51:24 set by hand to autoVerify: false, app running 72 bytes
08:53:42 still 72 bytes, autoVerify: false untouched for 138 s

Under 1.30096.1 the same edit was reverted to true after 28 seconds. That part of this report
is resolved, as is the startup case, which already held in 1.30096.1.

Still broken, and now much more precisely: the menu can only ever produce true

Two separate faults combine into a dead end.

1. The checkmark shown when the menu opens is not derived from the stored value.

08:57:46 a click wrote autoVerify: true 71 bytes, checkmark gone afterwards
08:59:32 menu opened again, nothing clicked
-> the checkmark is back
-> the file is unchanged: still true, timestamp still 08:57:46

The file said true, i.e. auto-verify enabled, which must render as unchecked. The menu
rendered it checked. Merely opening the menu wrote nothing.

2. Clicking the item always writes true.

08:57:46 click (checkmark removed) -> autoVerify: true
09:01:56 click (checkmark removed) -> autoVerify: true

Both clicks produced the same value. The correct value for "checkmark removed" is indeed
true, so each individual click is not wrong in isolation.

Together they form a loop with only one exit. The menu always opens checked; a click always
unchecks and writes true; reopening shows checked again. There is no sequence of menu actions
that results in autoVerify: false. Auto-verify cannot be switched off from the menu at all.

This also explains the symptom in the original report — "the checkmark is back when I reopen the
menu". It is a rendering fault, not a persistence fault, and I mis-attributed it at the time.

Workaround

Editing .claude/launch.json by hand works and now holds even while the app is running, which it
did not before. The documentation presents the file and the menu as two equivalent routes; at
present only the file route works.

````

level420 · 6 days ago

Re-tested on 2.26454.2. The menu entry has been reworded from "Disable automatic verification" to "Verify changes automatically", so the checkbox polarity is inverted, but the bug is the same in mirror image:

| | menu shows | each click writes |
|---|---|---|
| before ("Disable …") | always checked, i.e. off | "autoVerify": true |
| now ("Verify …") | always unchecked, i.e. off | "autoVerify": true |

Sequence on 2.26454.2, with .claude/launch.json starting at "autoVerify": false:

  1. Menu opens unchecked (matches the file). Click → file becomes true.
  2. Reopen: still unchecked, although the file now says true.
  3. Click again → file is rewritten with true (new timestamp, same content).

So the menu never reflects the stored value and can only ever write true; there is still no way back to false except editing the file by hand. Editing the file does stick.