{"version":"2.1.273","anchor":"cowork-file-read-denial-message-now-names-the-failed-field-g","canonical_anchor":"cowork-file-read-denial-message-now-names-the-failed-field-g","heading":"Cowork file-read denial message now names the failed field generically","tier":"internal","area":"Cowork","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.273\/e\/cowork-file-read-denial-message-now-names-the-failed-field-g","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.273","markdown":"### Cowork file-read denial message now names the failed field generically\n\nThe 'cannot read file' permission-denial message can now name a different failed field, not just file_path\n\n**What**\n\nThe internal message shown when Claude is denied permission to read a file (\"cannot read file ... the file could not be examined\") used to always refer to a hardcoded `file_path` field. It now accepts a parameter name, defaulting to `file_path`, so the same message can be reused when a different parameter is the one that failed.\n\n**Why**\n\nThis is a small internal cleanup that lets one deny-message helper serve tools or parameters other than `file_path`, rather than duplicating the message text for each one.\n\n- Area: Cowork\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 0\/5"}