libsqlite3-sys and all its dependents get recompiled whenever I switch between cargo b and cargo watch -x b

[Boscop]

When I build my crate (only whenever I switch between cargo b and cargo watch -x b!), it always recompiles a few deps that didn't change (starting with libsqlite3-sys):

   Compiling libsqlite3-sys v0.9.3
   Compiling diesel v1.3.3
   Compiling migrations_internals v1.3.0
   Compiling r2d2-diesel v1.0.0
   Compiling migrations_macros v1.3.0
   Compiling diesel_migrations v1.3.0

And then it recompiles my workspace's db crate that uses diesel, and all the other crates that depend on the db crate, so somehow libsqlite3-sys gets marked as dirty, but why?

It definitely didn't happen before I upgraded from diesel 0.16 (which used libsqlite3-sys 0.8.1) to diesel 1.3 (last week).
Do you have any idea what could cause this?

Maybe libsqlite3-sys 0.9.3 is reading some environment variables that are different with cargo-watch, and these env vars were not used in libsqlite3-sys 0.8.1?

Btw, it also happens when switching between cargo check and cargo watch -x r (but never when switching between cargo check & cargo b or cargo watch -x r & cargo watch -x b), so the defining characteristic is that this only happens when switching between building/checking with cargo "without cargo-watch" and "with cargo-watch".
So it must have something to do with cargo-watch, but only triggered by the new version of libsqlite3-sys somehow.

[Boscop]

Does cargo-watch run cargo with a different value for the PATH env var than the value it has outside of cargo-watch?
If yes, it's triggering this.

[passcod]

/home/.cargo/bin is prepended. But it's not a cargo-watch thing, nor a watchexec thing. (I.e. nowhere in the code does the PATH get modified, afaics.)

I made a script called cargo-sh with this:

#!/usr/bin/sh

shift
echo "$*"
exec $*

And calling it with cargo sh env yields the same PATH line as when running cargo watch -s env.

Thus, this is a thing that cargo does when calling subcommands.