Sandbox cleanup keeps symlinks you retargeted yourself, denying the new target instead of deleting the link.
What's wrong with this entry?
The pass that removes deny-listed paths which have become symlinks used to delete any link whose resolution changed. It now works out the sandbox's writable roots for the session, and if nothing the link resolves through lies inside one of them it treats the change as yours: the path is kept and its new target is denied for the next command instead.
- If the path became a real file or directory, that path is denied literally.
- Sparing is recorded as
tengu_sandbox_scrub_spared_unreachablewith a flag for whether it is still a symlink. - New handling for dangling links and for comparing path components case- and Unicode-normalisation-insensitively.
- Only applies on Linux, WSL and macOS; elsewhere the write-root lookup returns nothing and the old behaviour stands.
tengu_sandbox_scrub_spared_unreachable
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.236
macOS sandbox re-applies read and delete denials inside writable folders
Both mention sandbox
-
v2.1.236
Sandbox proxy no longer writes to sockets that have gone away
Both mention sandbox
-
v2.1.236
IPv6 hosts through the proxy
Both mention sandbox