By only allowing it to be on the PATH when you’re in a specific folder (eg. The binary only ever lives in project/bin, not $user/.shared/bin) and by making the binary filename have a prefix (eg. project-git) so you can’t possibly invoke it when expecting to call a normal cli command (eg git).
Since cargo manages these installs, both would be trivial for it to do; just inconvenient for cli app authors.
But this is not "sandboxed" in any conventional understanding of the term. "sandboxed" would mean that the binary has restricted access to resources like the filesystem, the network etc.
Ok, you’re right, sandboxed isn’t the right word; my bad.
However, it’s more isolated than what currently exists, even if it’s not totally isolated, and it’s an effort to prevent abuse, rather than doing nothing.
My point is that you can contain the impact of cli apps in various ways.
Since cargo manages these installs, both would be trivial for it to do; just inconvenient for cli app authors.