{"version":"2.1.309","anchor":"read-block-hardening-for-proc-and-devfd-paths","canonical_anchor":"read-block-hardening-for-proc-and-devfd-paths","heading":"Reading process details through \/proc and \/dev\/fd paths is blocked","tier":"notice","area":"Permissions","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.309\/e\/read-block-hardening-for-proc-and-devfd-paths","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.309","markdown":"### Reading process details through \/proc and \/dev\/fd paths is blocked\n\nPaths such as \/proc\/self\/environ, \/proc\/self\/cwd, \/dev\/fd and \/dev\/stdin are now treated as blocked reads\n\n**Unclear.** It is not stated which kinds of file read this blocking applies to.\n\n**What**\n\nOn Linux, special paths under `\/proc` and `\/dev` give access to a running program's details. Claude Code now treats these as blocked reads:\n\n- `\/proc\/self\/cwd`, `\/proc\/self\/fd`, `\/proc\/self\/environ`, `\/proc\/self\/cmdline` and similar paths such as `auxv`, `maps` and `smaps`\n\n- `\/dev\/fd` and `\/dev\/stdin`\n\n- `\/proc\/*\/root`\n\nIt follows working-folder links to their real location before checking.\n\n**Why**\n\nThese paths can expose secrets, such as environment variables holding passwords or tokens, without naming the real file. Blocking them closes that indirect way round read restrictions.\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: yes"}