Trying to hear about different patterns/methods users protect their systems against opportunistic supply chain attacks on their PCs, not servers.

One major exposure that I -- and I assume many others -- have, are shell & editor (say vim) plugins; including shell completions.

I'm trying to find a reasonable implementation for compartmentalization that offers (subjectively) reasonable security whilst not being too much in the way of day-to-day tasks.

For sandboxing implementation I'm leaning towards bubblewrap; no particular reason besides its relatively low level of CVEs and its simplicity.

Best separation I'm thinking towards is as follows:

1. window manager with programs launched from it are running outside of any sandboxing;
2. default shell sessions have full read/write of most locations, but no outside networking allowed; this is so the convenience offered by editor/shell plugins&extensions can be benefited from, while no data can directly be exfiled;
3. separate sandboxed sessions for domain-specific tasks such as development; e.g. network connection allowed, but filesystem access heavily restricted to the tools and source code being worked on;
4. separate shell sessions that are not sandboxed, but run a near-vanilla shell config. Need to make sure most daily programs started from it (such as vim) are either started in sandboxes, or use a vanilla config themselves as well.

1. what issues with above can you spot, and how have you solved mitigated PC sandboxing?
2. running containers from within the abovementioned development sandboxes -- any concerns/limitations? Passing socket from unsandboxed host is inevitable?
3. how to handle tools being called from outside the sandbox and from within? Say jq. Should such tools be started sandboxed if we're outside and non-sandboxed if already in a sandbox? No way to further limit jq blast radius in that case, as nested bubblewrap doesn't work?