{"version":"2.1.290","anchor":"sandbox-read-blocking-and-wsl-mount-parsing-rework","canonical_anchor":"sandbox-read-blocking-and-wsl-mount-parsing-rework","heading":"WSL drive detection and sandbox read rules were reworked","tier":"notice","area":"Elsewhere","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.290\/e\/sandbox-read-blocking-and-wsl-mount-parsing-rework","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.290","markdown":"### WSL drive detection and sandbox read rules were reworked\n\nOn WSL, Claude Code now finds Windows drives from \/proc\/self\/mountinfo, and the sandbox's read-blocking rules are built differently\n\n**Unclear.** The overall effect on what the sandbox allows or blocks is not clear.\n\n**What**\n\nOn WSL (Windows Subsystem for Linux, which runs Linux inside Windows), Claude Code now finds your Windows drives by reading `\/proc\/self\/mountinfo` instead of `\/proc\/self\/mounts`. Its error and status messages now name the new file.\n\nThe sandbox is a set of limits on which files and network addresses the commands Claude runs can reach. The code that builds those limits was restructured:\n\n- Paths blocked from reading (`denyRead`) are now always processed, rather than only in some cases\n\n- Paths to credential files are worked out in a different way\n\n**Why**\n\nThis touches how Claude Code serves cloud sessions on WSL and which files the sandbox lets commands read. If file access inside the sandbox behaves differently after updating, this rework is a likely place to look.\n\n- Area: Elsewhere\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}