{"version":"2.1.208","anchor":"bug-fixes","canonical_anchor":"bug-fixes","heading":"","tier":null,"area":null,"scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.208\/e\/bug-fixes","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.208","markdown":"- File deny rules now block edits, not just reads. A new clear error message is shown when a file is covered by a Read deny rule and the user attempts to edit it: \"File is covered by a Read deny rule in your permission settings and cannot be edited.\" (search for `\"File is covered by a Read deny rule\"`)\n\n- Ripgrep usage errors (invalid patterns, unsupported glob syntax, unknown file types) are now caught and reported as `RipgrepUsageError` rather than surfacing as raw subprocess failures. The error message includes the rejection reason: \"Search failed \u2014 ripgrep rejected the pattern, glob, or file type without searching\" (search for `\"Search failed \u2014 ripgrep rejected the pattern\"`)\n\n- The `apiKeyHelper` script failure notification is now a clear user-facing message: \"Your apiKeyHelper script is failing \u00b7 This usually means you need to re-authenticate with your provider \u00b7 Run \/status to see the script's error output\" (search for `\"Your apiKeyHelper script is failing\"`)\n\n- Symlink resolution in the Linux sandbox deny-path logic was improved: deny paths are now resolved through symlinks before enforcement to avoid false positives when a deny path target is accessed via a symlink (search for `\"[Sandbox Linux] Resolve symlinked deny path\"`)"}