{"version":"2.1.310","anchor":"read-tool-device-file-check-replaced-by-a-helper-that-return","canonical_anchor":"read-tool-device-file-check-replaced-by-a-helper-that-return","heading":"Device and process file path checks tightened","tier":"notice","area":"File Reading","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.310\/e\/read-tool-device-file-check-replaced-by-a-helper-that-return","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.310","markdown":"### Device and process file path checks tightened\n\nThe check that spots device and process paths such as \/proc now normalizes paths and matches more forms, and the Read refusal names them as resolved\n\n**What**\n\nSome paths, such as `\/proc\/*\/fd\/0-2` on Linux, name devices or running processes instead of ordinary files, and the Read tool (which reads files for Claude) does not read them. The check for these paths changed:\n\n- The check now normalizes a path (rewrites it into one standard form) before testing it, and tests one more pattern, so more spellings and special files are recognised.\n\n- The Read tool's fixed refusal, \"Cannot read '...': this path names a device or process file that this tool does not read.\", is replaced by a helper that builds the message from the resolved path spellings. Error code 9 is kept.\n\nThe Read tool's own description is unchanged from the previous release in the capture taken under this release.\n\n**Why**\n\nIn practice, paths written in unusual ways that point at a device or process file are now caught by the same safety check instead of slipping past it.\n\n- Area: File Reading\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}