{"version":"2.1.282","anchor":"desktop-host-dialog-approval-path-for-settings-file-edits-is","canonical_anchor":"desktop-host-dialog-approval-path-for-settings-file-edits-is","heading":"Approving settings-file edits from the desktop app's permission card is still off","tier":"soon","area":"Desktop","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282\/e\/desktop-host-dialog-approval-path-for-settings-file-edits-is","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282","markdown":"### Approving settings-file edits from the desktop app's permission card is still off\n\nThe code that records a desktop-app approval of a settings-file edit is now filled in, but a check that always says no keeps every edit going to \/settings-review\n\n**Unclear.** It is unclear whether the permission-card route is reached some other way today.\n\n**What**\n\nWhen Claude tries to edit one of Claude Code's own settings files, the edit either applies after you approve it on the desktop app's permission card (the approval prompt the app shows) or is held for review in `\/settings-review`. Which one happens depends on whether the desktop app has confirmed your approval.\n\nThe part that records that confirmation used to be empty. It now stores the tool name, the file path and a fingerprint of the content being written. Both recording and reading the confirmation also depend on a new check that always answers no, so the confirmation is never treated as given. Edits to settings files still go to `\/settings-review` and are not applied from the permission card.\n\n**Why**\n\nThis is the unfinished part of letting desktop users approve settings changes straight from the permission card. It is switched off in the code itself, not by a remote setting, so only a new build can turn it on.\n\n- Area: Desktop\n- Names: `\/settings-review`\n- Tier: Nothing to try yet\n- Useful: 3\/5\n- Signal: 4\/5\n- Present in the build but not switched on"}