{"version":"2.1.280","anchor":"readwrite-permission-messages-now-say-when-a-path-resolves","canonical_anchor":"readwrite-permission-messages-now-say-when-a-path-resolves","heading":"Permission checks now detect and explain symlink-mediated path escapes","tier":"notice","area":"Permissions","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/readwrite-permission-messages-now-say-when-a-path-resolves","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### Permission checks now detect and explain symlink-mediated path escapes\n\nRead and write permission checks now catch and explain when a path escapes the working directory through a symlink\n\n**What**\n\n- When a read or write target's real path, after resolving symlinks, lands outside the allowed working directories, the permission-ask message now explicitly says the path \"resolves through a symlink to\" the outside location. If the symlink chain can't be resolved at all, the operation is denied outright.\n\n- A new helper (`r2e`) is consulted after a write is otherwise allowed or denied, to catch cases where the operation would actually land outside the intended location via a symlink, adding a dedicated safety-check reason and message for that case.\n\n**Why** This closes a gap where a symlink could quietly redirect a read or write outside the intended working directory, and makes the resulting permission prompt clearer about what's actually happening.\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}