[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
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": falseto.claude/launch.json, or toggle it from the server dropdown menu. — https://code.claude.com/docs/en/desktop#auto-verify-changes
- 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.
- A hand-written
"autoVerify": falseis overwritten. The app replaces it with"autoVerify": trueabout half a minute after start. Across a whole session, every value the app itself wrote wastrue; the only times the file ever heldfalsewere when it was written by hand.
- 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.jsonheld"autoVerify": true(auto-verify enabled).
The UI is German here; the item reads "Automatische Verifizierung deaktivieren".
What Should Happen?
- Toggling the menu item persists across reopening the menu and across restarts.
- A hand-written
"autoVerify": falsein.claude/launch.jsonis honoured and not overwritten, as the documentation states. - 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
- Open a local session on a project folder and open the Browser pane.
- 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)
- Toggle "Disable automatic verification".
- 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
- Quit the app completely (end all processes, not just the window).
- Create
.claude/launch.jsonin the project folder with:
{
"version": "0.0.1",
"autoVerify": false,
"configurations": []
}
- Start the app and open that project.
- 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.
3 Comments
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": falsein 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.jsonat startup and does honourautoVerify: 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 notkeep its checkmark when toggled during a session.
Under 1.28929.0 the startup path failed as well: a hand-written
falsewas overwritten about 32seconds 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": falsein.claude/launch.json, then start the app. That sticks. The documentation does not mention thatthe app must be closed, and the menu route remains unusable.
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
trueafter 28 seconds. That part of this reportis 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
trueTwo 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 menurendered 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 actionsthat 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.jsonby hand works and now holds even while the app is running, which itdid not before. The documentation presents the file and the menu as two equivalent routes; at
present only the file route works.
````
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.jsonstarting at"autoVerify": false:true.true.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 tofalseexcept editing the file by hand. Editing the file does stick.