clippy sometimes complains about not-passed command line arguments!

Summary

I recently experienced this:

cargo +stable clippy --offline -p tor-dirmgr --all-features --all-targets --
...
error: Unrecognized option: 'nocapture'

The --nocapture was an argument I had previously passed to cargo test in the same tree: previously I had run cargo +stable test --offline -p tor-dirmgr --all-features --all-targets -- --nocapture bdtest.

Deleting target/ made the problem go away. Storing the current command line arguments in target/ seems wrong to me. What if multiple commands are run at once? Quite aside from the fact that apparently sometimes previous values can be erroneously reused.

Reproducer

I have tried to reproduce the problem, but simply going back and forth between cargo test -- --nocapture and cargo clippy doesn't seem sufficient. This is not the first time I have seen this very strange behaviour. So it's not a one-off.

I could perhaps preserve target/ next time.

Version

rustcargo@zealot:/volatile/rustcargo/Rustup/Arti/arti$ rustc +stable -vV
rustc 1.64.0 (a55dd71d5 2022-09-19)
binary: rustc
commit-hash: a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52
commit-date: 2022-09-19
host: x86_64-unknown-linux-gnu
release: 1.64.0
LLVM version: 14.0.6
rustcargo@zealot:/volatile/rustcargo/Rustup/Arti/arti$

Additional Labels

No response

Start with the cargo test and cargo clippy commands in the report, preserving target/ while switching between them to seek a reproducible case. Trace how command-line arguments are retained in target/ and verify that concurrent or successive commands cannot reuse the wrong arguments; no source file or test is named in the issue.