dpc - Posts

LLM Reviews in cargo-crev

2026-04-12T00:00:00+00:00

There has been lots of chatting about software supply chain security recently, motivated by popular package exploits.</p>

Well, I have some relevant news: cargo-crev</a> now supports LLM-assisted code reviews. Go try it!</p>

Read on to get more information and background.</p>

History

LLMs getting good at finding issues

#</a>
</h2>
Just a few weeks ago I was reading some articles about new LLM
models finding non-trivial security issues, and Linux kernel and curl
developers admitting that after a deluge of mostly worthless slop security reports
they used to complain about, now they tend to receive actually worthwhile
AI-assisted bug and security reports. It reminded me about cargo-crev</code>
and I realized that AI can actually fill the gap that made me
doubt it.</p>
I'm not trying to overhype LLMs. But the fact is that
they can do, and in high volume, what developers themselves have
no time for: the 90/10 security scanning that was otherwise quite hard
to automate.</p>
An LLM can easily and reliably check if a code version published
on https://crates.io matches the code published in git.</p>
An LLM can easily scan build.rs</code> and the rest of the code and
look if anything looks out of place.</p>
It is actually very hard to hide key-stealing malware
in a package that was supposed to format units, etc.</p>
Especially in Rust, doing things that are wrong or
out of place creates a lot of noise, making such code
easy to notice, even by an LLM reviewer.</p>
It might not be a silver bullet, but it is definitely
better than doing nothing.</p>
How to use it#</a>
</h2>
Note: In the initial release cargo-crev</code> supports
only Claude Code agent. If you're interested in adding
support for other coding agents, it should be relatively
easy — most scaffolding is already there. Feel free to chat
and create a PR.</p>
Since version 0.27 cargo-crev</code> has a built-in
review loop.</p>
cargo crev ai review-loop --iterations 10</span></span></code></pre>
which will start the agent 10 times, each time
selecting and reviewing a single dependency.</p>
The agent will produce&update a single shell script
that can be used to conveniently review and sign
all reviews.</p>
While the above is meant as a standard mass-review flow,
the core built-in agent review skill is available as an output of:</p>
cargo crev ai skill review</span></span></code></pre>
and it should be easy for anyone to modify it and/or build their own
LLM-assisted workflows.</p>
How it works#</a>
</h2>
The core change is that Crev's reviews now have
fields to indicate that an LLM was used for the review</a>.</p>
The rest is just relatively minor functionality to make producing
LLM reviews convenient end to end.</p>
For people skeptical of LLMs, options to ignore LLM-generated reviews
have been and will be added where appropriate. You can just
ignore the slop reviews if you don't trust them, fine with me.</p>
How well</em> it works#</a>
</h2>
While working on this feature and testing it myself, I have produced
quite a few LLM-assisted reviews</a>.
Judge by yourself.</p>
To me these meet the bar of being useful. And they turned some spare
capacity from my Claude subscription into something that I otherwise
would not be able to do myself.</p>
Summary#</a>
</h2>
This is only an initial attempt at harnessing the AI in cargo-crev.
There still might be lots of things to improve and extend, but we have
to start somewhere.</p>
If you like the idea and find it promising, I encourage you
to try it out, give some feedback, and submit improvements.</p>



I don't want your PRs anymore
2026-04-06T00:00:00+00:00
I really appreciate that you're enjoying the software I'm maintaining
and want to help. But we need to rethink this collaboration, because
I feel like we're increasingly wasting each other's time.</p>
Why I don't want to merge your PR#</a>
</h3>
Since I don't really know you, I always have to assume that you might be trying
to sneak in something malicious along with your changes, which makes
reviewing and merging them riskier than implementing them myself.</p>
On top of that, there are a lot of personal and subjective aspects to code.
You might have certain preferences about formatting,
style, structure, dependencies, and approach, and I have mine.</p>
Then we often need to synchronize with respect to review, CI runs, merge conflicts, etc.</p>
And then there's this common back-and-forth round-trip between the
contributor and maintainer, which is just delaying things.</p>
Even before LLMs, writing the code was not the main bottleneck for me. But
writing code did take time, so a solid, working, easy-to-review PR was
often worth the small extra risk and inconvenience.</p>
With LLMs becoming quite good at implementing things, that tradeoff
is almost never true anymore.</p>
While I still need to review LLM-generated code, I generally don't have to worry about
it being malicious the way an unknown contributor's code could be. I've already
codified a lot of my coding preferences and style guidelines for my LLM.
And I can rapidly iterate at my own pace without having to synchronize with
another human who might be in a different timezone.</p>
For these reasons, it's just easier if I make the code changes
myself (with the help of an LLM).</p>
The nature of software development has shifted#</a>
</h3>
It's increasingly apparent that "the source code" is less "source"
and more "code" — an intermediate formalized layer between
ideas in the developer's head and instructions for the computer to
execute. It's always been this way, but now, with the code itself
being easier to generate automatically, it's just more visible.</p>
There's a wide range of reactions to coding agents out there,
from banning them to proclaiming that coding is dead and vibecoding
is the future. Personally, as things are right now, I sit somewhere in the middle.
I come up with the design, then let my agent do a lot of the actual writing, and then I review
and refine the result.</p>
I could get huge amounts of code written, but I'm bottlenecked on:</p>

understanding — reading the existing code to be able to reason about it;</li>
designing — coming up with the right changes and architecture;</li>
reviewing — ensuring that the code is doing what I wanted.</li>
</ul>
The code in your PR doesn't help me much with any of these.
So let's skip it — don't attempt to implement code changes
with the goal of merging them into the codebase.</p>
How can you help instead#</a>
</h3>
As the "writing the code" part is becoming less valuable, all other ways
of helping maintainers become relatively higher value.</p>
Give feedback#</a>
</h4>
As I'm busy implementing things, I often don't have much time
to actually use them, or do good research on how to improve them.</p>
Users telling me what works well and what could be improved can be very helpful.</p>
Discuss ideas#</a>
</h4>
I don't know everything, and discussing things with
other people with different experiences and perspectives
can help me understand what I should be building and how.</p>
Report and investigate bugs#</a>
</h4>
A good bug report is 3/4 of the bug itself being fixed.</p>
If you spotted a problem, please describe it well, and even
do the debugging to figure out how to reproduce it and
where exactly the problem is.</p>
Then discuss potential solutions.</p>
Prototype changes#</a>
</h4>
Send me a reference PR and/or the prompt you used to produce it.</p>
Yes, I know I just said that I don't want your PRs. So let me
explain. With LLMs, it's easier for me to get my own LLM to make the change
and then review it myself.</p>
BUT — using code for illustrative purposes still makes sense.
A quick glance at code implementing something can be helpful,
even if I don't end up merging it.</p>
And if you share the actual "source" (prompt) to produce the "code",
I can reuse and refine it, saving time.</p>
Review code and point out problems#</a>
</h4>
As I'm bottlenecked on reviews, an extra pair of eyes helps.</p>
Fork the code and report back#</a>
</h4>
Don't be afraid of forking the code and changing it however you want.</p>
Having to come up with designs supporting multiple use cases,
forming consensus, debating best outcomes, looking for compromises, etc.
is very time-consuming.</p>
LLMs enable a great deal of software customizability. You can
make the changes you want by yourself faster and easier than ever,
and then rebase them (or not) on top of upstream
at your own pace.</p>
Just fork. Add support for your own use case, do things your way,
ask neither for permission nor forgiveness.</p>
As a maintainer, this saves me time too. And in the end, maybe both of us
can learn something from your version taking its own route.</p>


Reviewing my Framework 13 Laptops: the old vs new
2026-03-31T00:00:00+00:00
Since August 2022 I was using a FW13 12th Gen Intel as my primary laptop. I didn't strictly need a new one, as it was still working perfectly fine. But upgrading after 4 years doesn't seem crazy or too excessive, and I'm worried about the global economy and supply chains going forward, so I decided to get a new one a bit earlier than I usually would.</p>
The old one will serve as a family device, and if need be, a spare part donor for the new one. One of the advantages of an upgradable laptop like this. I might get it a case and convert it to a headless/desktop device eventually. Would make a nice low-power home server.</p>
I just recently got the new FW13 with Ryzen AI 9 HX 370 delivered, set it up, used it for a few days, and I figured it's a good time to write some thoughts about both and my Framework Laptop experience overall.</p>
The old one#</a>
</h3>
The old one served me well for almost 4 years, which is appreciated. After all this time
it looks close to brand new. Not much visible wear.</p>
It has enough power to compile Rust projects without being painfully slow,
though I typically work over ssh on a desktop machine, which is 3x-6x
faster at heavy tasks like that. I'll post some benchmarks at the end.</p>
It always worked well with Linux and had good support in the Open Source community wherever it matters, e.g. pre-made modules for nixos-hardware</code></a> early on. All the devices I cared about worked well.</p>
I loved (and still do) the ease of being able to open, inspect, dedust, replace parts, etc. E.g. I added
an NVMe radiator because I had a spare one around, and it fits, so why not?</p>
I had to replace the input cover though, as I was affected by keys intermittently not working</a>.
Replacement was super easy, the part was about $100. But it was quite an annoying problem to debug until the FW Team published their findings.</p>
The second complaint would be the BIOS update situation for 12th Gen Intel, which turned out to be hopeless</a>.
I personally didn't care much, but between 3rd party BIOS vendors and other complications, the BIOS update story went quite wrong for this model.</p>
The last complaint would be the wobbly lid hinge. It was annoying sometimes: at steep angles the lid would not hold position and when unstable or moved it would wobble a little.</p>
The battery life was mid. It did improve due to some firmware fixes, etc. but
it was never good. I'm not much of a traveler, and mostly need the battery
to move the laptop from the dock to the dinner table or a couch,
so I was aware of that before buying and didn't care.</p>
I was very happy about the hardware battery charge limit. Except when traveling,
I kept it set to 60%, and didn't notice any battery degradation over the years,
despite having it plugged in 99% of the time.</p>
I love the physical toggles for microphone and camera. That feature alone
always made FW13 feel like a laptop for people like me — the kind who join morning calls
in their underwear.
Just kidding (or am I?). People who care about cybersecurity, privacy, etc.</p>
The new#</a>
</h3>
It might sound weird, but I really appreciate that the new laptop... is in the form factor exactly the same as the old one. Maybe I'm too much on the spectrum, heh. No need to adjust to a new key layout, everything feels familiar, the microphone and camera physical switches are still there. No negative surprises.</p>
The new higher DPI screen is soo nice. Immediately noticeable improvement.</p>
The hinge is fixed. Now it is very high-force, maybe even a bit too much.
Does opening the lid count as exercise?</p>
The specs are a significant improvement, at least for my needs (compiling Rust code).</p>
The desktop UI feels even smoother than before, especially with an external
monitor attached. Overall, probably a combination of the improved built-in
screen at 120Hz (60Hz on the old one) and better specs.</p>
The old laptop under load ran quite hot and spun the CPU fan like
a lawn mower. So far, the new one handles the load much more gracefully: cooler and quieter.</p>
Looks to me like the fwupdmgr dealt well with firmware updates
right away, so hopefully the BIOS story will be better this time.</p>
I'm not sure about the battery yet. Again - I don't really use it much,
and I capped it at 60% right away too. I don't expect miracles.
There is plenty of info online with proper measurements.</p>
Summary#</a>
</h3>
As you could see, I was somewhat of an early Framework adopter,
and fine with some bumps along the way. I need a laptop that is
a bit like a desktop: good power, open, repairable, and I don't
care much about battery capacity.</p>
I'm happy to see that everything that was not ideal
in the previous version is now fixed, and the whole
laptop is just a more polished and capable version
of what I already liked.</p>
Benchmarks#</a>
</h3>
The main project I'm working on has a compilation benchmark</a>, so I'm going to use it for real-life performance.
It's a relatively large and heavy Rust codebase.</p>
ren - my desktop#</a>
</h5>
dpc@ren</span></span>
-------</span></span>
OS: NixOS 26.05 (Yarara) x86_64</span></span>
Kernel: Linux 6.19.9</span></span>
CPU: AMD Ryzen 9 7950X3D (32) @ 4.04 GHz</span></span>
Memory: 26.22 GiB / 62.01 GiB (42%)</span></span>
Swap: 5.26 GiB / 31.00 GiB (17%)</span></span>
Disk (/): 11.47 MiB / 31.00 GiB (0%) - tmpfs</span></span>
Disk (/bin): 2.61 TiB / 6.84 TiB (38%) - bcachefs [Read-only]</span></span>
</span>
</span>
Date: 2026-03-30</span></span>
Commit: 08fb6c1b613</span></span>
                       total    user     sys</span></span>
Full  check   debug:   62.21  986.43  145.05</span></span>
Incr  check   debug:    4.38   10.46    8.01</span></span>
Full  build   debug:  111.77 2129.55  213.69</span></span>
Incr  build   debug:   13.69   38.91   27.34</span></span>
Full  check release:   54.47  566.00  132.61</span></span>
Incr  check release:   15.77   39.94    7.89</span></span>
Full  build release:  448.37 12471.30  674.43</span></span>
Incr  build release:  371.44 10790.08  399.68</span></span></code></pre>tlb - new Framework 13#</a>
</h5>
dpc@tlb</span></span>
-------</span></span>
OS: NixOS 26.05 (Yarara) x86_64</span></span>
Kernel: Linux 6.19.9</span></span>
CPU: AMD Ryzen AI 9 HX 370 (24) @ 1.95 GHz</span></span>
Memory: 14.24 GiB / 93.59 GiB (15%)</span></span>
Swap: 0 B / 46.80 GiB (0%)</span></span>
Disk (/): 10.86 MiB / 46.80 GiB (0%) - tmpfs</span></span>
Disk (/bin): 91.67 GiB / 6.69 TiB (1%) - bcachefs [Read-only]</span></span>
</span>
</span>
Date: 2026-03-30</span></span>
Commit: 08fb6c1b613</span></span>
                       total    user     sys</span></span>
Full  check   debug:  162.62 2473.10  164.12</span></span>
Incr  check   debug:    7.66   21.89    8.53</span></span>
Full  build   debug:  317.64 5398.69  252.56</span></span>
Incr  build   debug:   19.44   69.70   21.61</span></span>
Full  check release:  129.30 1324.88  144.16</span></span>
Incr  check release:   37.23   95.91    9.08</span></span>
Full  build release: 1488.11 31536.63  726.96</span></span>
Incr  build release: HANG? cargo bug?</span></span></code></pre>mutex - old Framework 13#</a>
</h5>
dpc@mutex</span></span>
---------</span></span>
OS: NixOS 26.05 (Yarara) x86_64</span></span>
Kernel: Linux 6.19.9</span></span>
CPU: 12th Gen Intel(R) Core(TM) i7-1280P (20) @ 3.60 GHz</span></span>
Memory: 3.76 GiB / 62.51 GiB (6%)</span></span>
Swap: 0 B / 40.05 GiB (0%)</span></span>
Disk (/): 11.96 MiB / 31.26 GiB (0%) - tmpfs</span></span>
Disk (/bin): 755.77 GiB / 906.66 GiB (83%) - ext4 [Read-only]</span></span>
</span>
Date: 2026-03-31</span></span>
Commit: 5272f1734c4</span></span>
                       total    user     sys</span></span>
Full  check   debug:  226.67 2951.83  196.04</span></span>
Incr  check   debug:    8.78   25.72   10.34</span></span>
Full  build   debug:  433.46 6511.59  309.13</span></span>
Incr  build   debug:   28.67   81.74   27.63</span></span>
Full  check release:  157.38 1606.74  183.38</span></span>
Incr  check release:   42.21  107.07   12.39</span></span>
Full  build release: 2062.62 38336.06  860.68</span></span>
Incr  build release: HANG?</span></span></code></pre>


BubbleWrap your dev env and agents
2026-03-25T00:00:00+00:00
OK, so the world is collapsing, everything is getting hacked,
all dependencies are probably stealing keys and mining crypto,
slop is everywhere, and I'm part of the problem.</p>
So what do I do? I'm going to isolate!</a></p>
I had this in mind for a long while, but only recently
LLM agents became good enough that I actually find it
really useful to let them go without babysitting every
command they are trying to run.</p>
So the goals are:</p>

protect my systems from the slopus,</li>
protect my systems from malicious dependencies (at least somewhat),</li>
retain the usual UX.</li>
</ul>
Because of the last point, I am not going to be doing
separate user account, or a separate VM, or play with dockers.</p>
What I'm going to do is to use the BubbleWrap</a>,
to remount only parts of host system and home directory, and most
of them in read-only mode. This way my tooling
and general DX remains almost exactly the same,
but if the Slopus has an episode of psychosis,
or pulls in a cryptomining malware, there is
only so much damage that it can do.</p>
So the core of this system is the isolate</code> script:</p>
#!/usr/bin/env bash</span></span>
</span>
set</span> -euo</span> pipefail</span></span>
</span>
# Skip re-isolating if already inside an isolated environment</span></span>
if</span> [[</span> -n</span> "</span>${</span>ISOLATE_ENV</span>:-}</span>"</span> ]];</span> then</span></span>
	>&2</span> echo</span> "warning: already isolated"</span></span>
	exec</span> "</span>$</span>@"</span></span>
fi</span></span>
</span>
tiocsti_path</span>=</span>"/proc/sys/dev/tty/legacy_tiocsti"</span></span>
if</span> [</span> ! -f</span> "</span>$tiocsti_path</span>"</span> ]</span> ||</span> [</span> "$(</span>cat</span> "</span>$tiocsti_path</span>")"</span> !=</span> "0"</span> ];</span> then</span></span>
	>&2</span> echo</span> "warning: TIOCSTI not disabled"</span></span>
fi</span></span>
</span>
args</span>=</span>()</span></span>
</span>
args</span>+=</span>(</span></span>
	--dev-bind /dev /dev</span> \</span></span>
	--proc /proc</span> \</span></span>
	--tmpfs /tmp</span> \</span></span>
	--tmpfs /run</span> \</span></span>
 	--setenv PROMPT_ENV_INDICATOR "isolated"</span> \</span></span>
 	--setenv ISOLATE_ENV "$(</span>pwd</span>)"</span></span>
)</span></span>
</span>
for</span> p</span> in</span> \</span></span>
	/bin</span> \</span></span>
	/usr/bin</span> \</span></span>
	/etc</span> \</span></span>
	/nix</span> \</span></span>
	/run/current-system</span> \</span></span>
	"</span>$HOME</span>/bin"</span> \</span></span>
	"</span>$HOME</span>/.config"</span> \</span></span>
	"</span>$HOME</span>/nix/dot"</span> \</span></span>
	"</span>$HOME</span>/.gitconfig"</span> \</span></span>
	"</span>$HOME</span>/.nix-profile"</span> \</span></span>
	"</span>$HOME</span>/.local/share/direnv/allow/"</span> \</span></span>
	;</span> do</span></span>
	args</span>+=</span>(</span>--ro-bind "</span>$p</span>" "</span>$p</span>"</span>)</span></span>
done</span></span>
</span>
for</span> p</span> in</span> \</span></span>
	"</span>$HOME</span>/.cargo"</span> \</span></span>
	"</span>$HOME</span>/.claude"</span> \</span></span>
	"</span>$HOME</span>/.claude.json"</span> \</span></span>
	"</span>$HOME</span>/nix/dot/.claude"</span> \</span></span>
	"</span>$XDG_RUNTIME_DIR</span>/gnupg/S.gpg-agent"</span> \</span></span>
	"$(</span>pwd</span>)"</span>\</span></span>
	;</span> do</span></span>
	args</span>+=</span>(</span>--bind "</span>$p</span>" "</span>$p</span>"</span>)</span></span>
done</span></span>
</span>
if</span> [[</span> -n</span> "</span>${</span>NIRI_SOCKET</span>:-}</span>"</span> && -S</span> "</span>$NIRI_SOCKET</span>"</span> ]];</span> then</span></span>
	args</span>+=</span>(</span>--bind "</span>$NIRI_SOCKET</span>" "</span>$NIRI_SOCKET</span>"</span>)</span></span>
	args</span>+=</span>(</span>--setenv NIRI_SOCKET "</span>$NIRI_SOCKET</span>"</span>)</span></span>
fi</span></span>
</span>
args</span>+=</span>(</span></span>
 	--dir "</span>$HOME</span>/.gnupg"</span> \</span></span>
 	--chmod</span> 0700</span> "</span>$HOME</span>/.gnupg"</span> \</span></span>
)</span></span>
</span>
# Source extra config (e.g. set by auto-isolate) to allow</span></span>
# project-specific additions to args</span></span>
if</span> [[</span> -n</span> "</span>${</span>ISOLATE_EXTRA_CONFIG</span>:-}</span>"</span> && -f</span> "</span>$ISOLATE_EXTRA_CONFIG</span>"</span> ]];</span> then</span></span>
	source</span> "</span>$ISOLATE_EXTRA_CONFIG</span>"</span></span>
	# Hide the config file inside the sandbox by overlaying /dev/null</span></span>
	args</span>+=</span>(</span>--ro-bind /dev/null "</span>$ISOLATE_EXTRA_CONFIG</span>"</span>)</span></span>
fi</span></span>
</span>
exec</span> bwrap</span> \</span></span>
	"</span>${</span>args</span>[</span>@</span>]</span>}</span>"</span> \</span></span>
	"</span>$</span>@"</span></span></code></pre>
I'm not going to spend time explaining every detail here,
please read the Bubblewrap docs, or ask your local LLM.</p>
But if you, dear reader, are planning to do the same/similar thing,
you'll probably want to go over each path and consider
implications. E.g. I'm using a fancy Yubikey SSH/GPG setup</a>
and I need to touch the hardware yubikey every time I ssh
somewhere. Because of that I'm not afraid of mounting the ssh/gpg
socket into the isolated environment.</p>
Anyway, in a nutshell: isolate</code> will run a given command
in an environment where almost only the current working directory
is writable, and rest are only the bare minimum parts needed
to get things working, mostly in read-only mode. Kind-a, mostly.
The goal here is a good enough security and robustness without
sacrificing almost any DX.</p>
Thanks to using Nix, the first thing I'm going to use this isolate</code>
script to wrap Slopus. That guy should never get a full
access to anything important directly.</p>
Inside my system's flake.nix</code> in the main overlay I have something like this:</p>
            claude-code</span> =</span></span>
              let</span></span>
                orig</span> =</span> pkgs-unstable</span>.</span>claude-code</span>;</span></span>
              in</span></span>
              final</span>.</span>writeShellScriptBin</span> "claude" ''</span></span>
                exec env CARGO_TERM_QUIET=true PATH="</span>${</span>final</span>.</span>not-git</span>}</span>/bin:$PATH" </span>${</span>./dot/bin/isolate</span>} ${</span>orig</span>}</span>/bin/claude "$@"</span></span>
              ''</span>;</span></span></code></pre>
This makes Slopus always start in an isolated environment,
so I can't forget about it. I also replace git</code> with a wrapper
reminding Slopus that we're using Jujutsu, and make cargo build</code> less
noisy by default to (maybe) save some tokens.</p>
Then I want to automate entering isolated environment
in every project I'm working on.</p>
For that I have auto-isolate</code>:</p>
#!/usr/bin/env bash</span></span>
</span>
set</span> -euo</span> pipefail</span></span>
</span>
if</span> [[</span> ! -x</span> "</span>$HOME</span>/bin/isolate"</span> ]];</span> then</span></span>
	>&2</span> echo</span> "warning: </span>$HOME</span>/bin/isolate not found, skipping isolation"</span></span>
	exec</span> "</span>$</span>@"</span></span>
fi</span></span>
</span>
dir</span>=</span>"$(</span>pwd</span>)"</span></span>
while</span> true</span>;</span> do</span></span>
	if</span> [[</span> -f</span> "</span>$dir</span>/.isolate"</span> ]];</span> then</span></span>
		exec</span> env ISOLATE_EXTRA_CONFIG="</span>$dir</span>/.isolate"</span> $HOME</span>/bin/isolate "</span>$</span>@"</span></span>
	fi</span></span>
	if</span> [[</span> "</span>$dir</span>"</span> ==</span> "/"</span> ]];</span> then</span></span>
		break</span></span>
	fi</span></span>
	dir</span>=</span>"$(</span>dirname</span> "</span>$dir</span>")"</span></span>
done</span></span>
</span>
exec</span> "</span>$</span>@"</span></span></code></pre>
auto-isolate</code> will automatically call isolate</code> for a given
command if it can find .isolate</code> in current working dir
or any ancestor dir.</p>
One could wire it in a shell startup file, but since I have
a whole system for working in the CLI heavily rooted in tmux,
I am going to put it in ~/.config/tmux/tmux.conf</code> like this:</p>
set-option -g default-command "$HOME/bin/auto-isolate ${SHELL}"</span></span>
# in case I want to actually do something outside of the isolated env constrains</span></span>
bind E new-window "${SHELL}"</span></span></code></pre>
This way every time I'm starting a new pane in tmux,
it will trigger auto-isolate</code>. Now I touch ~/lab/.isolate</code> and
since all my dev projects are always inside ~/lab</code> I pretty much
can't ever forget to isolate</code> my projects.</p>
If you haven't noticed before, the isolate</code> script supports ISOLATE_EXTRA_CONFIG</code>
which allows adding project-specific modifications to the isolated
environment. E.g. for a little GUI project I'm working on, I had to
create following .isolate</code> file:</p>
if</span> [[</span> -n</span> "</span>$WAYLAND_DISPLAY</span>"</span> ]];</span> then</span></span>
    args</span>+=</span>(</span>--ro-bind "</span>$XDG_RUNTIME_DIR</span>/</span>$WAYLAND_DISPLAY</span>" "</span>$XDG_RUNTIME_DIR</span>/</span>$WAYLAND_DISPLAY</span>"</span>)</span></span>
fi</span></span>
</span>
args</span>+=</span>(</span></span>
	--bind /dev/dri/ /dev/dri/</span> \</span></span>
	--bind /dev/shm /dev/shm</span> \</span></span>
	--bind /tmp/.X11-unix/ /tmp/.X11-unix/</span> \</span></span>
	--bind /run/opengl-driver/lib/ /run/opengl-driver/lib/</span></span>
)</span></span></code></pre>
so it can show me the UI, when I run cargo r</code>.</p>