Repository navigation
Add -C <DIR> flag to cargo to change directory before invoking #10098
Description
Problem
Cargo infers the manifest path and reads config based on the current directory. Plugins may potentially locate other config this same way. Cargo commands offer a --manifest-path flag to override the manifest, but this doesn't override config.
For example, given the following:
> cat bin/foo/.cargo/config.toml
[build]
target = "wasm32-unknown-unknown"
target-dir = "../../target"
> cargo build --manifest-path bin/foo/Cargo.toml
The resulting build will use the host platform instead of wasm32-unknown-unknown and the build artifacts will end up in bin/foo/target. But were I to run cd bin/foo && cargo build it would use the correct target and target dir.
Proposed Solution
Cargo should have a flag -C <DIR> (or --directory <DIR>) that exists at the top level rather than in the subcommands. This flag would cause cargo to change its working directory to the specified one before processing any commands or loading any config. It would be roughly equivalent to ( cd <DIR> && cargo … ).
Besides fixing the issue of loading cargo config, this is also a simpler interface for end users than --manifest-path as it means they don't have to worry about where the specific Cargo.toml file is, they can just run cargo as though it were in a specific directory.
This flag is inspired by both make and git which offer the same -C <DIR> (make has the long --directory form, I don't believe git has a long form). The desired behavior here should be based on git as it also defines how multiple -C flags interact (subsequent ones are interpreted relative to the earlier ones). Like git, any other flags or parameters that take relative paths should then be interpreted relative to the working directory caused by the -C option.
Notes
Regarding rustup and rust-toolchain.toml overrides, I'm inclined to say rustup should honor this flag as well and interpret it prior to locating an override file. The idea here is that saying cargo -C $path … should behave indistinguishably from running cargo within that path.
Activity
lilyball commentedon Nov 19, 2021
This request was inspired by my surprised at
cargo build --manifest-path bin/foo/Cargo.tomlnot applying the config frombin/foo/.cargo/config.toml. I considered filing that as a bug, but I'm not sure what the actual correct behavior there should be, whereas a-Cflag has an obvious answer (and is easier to use).thomcc commentedon Nov 30, 2021
Yeah, I hit this issue too. I think ideally
--manifest-pathmade cargo do the right thing here, although I guess that would be a breaking change, and I can see some use cases for it using the current directory.Eh2406 commentedon Dec 10, 2021
I believe that @joshtriplett have brought this up at cargo meetings before, but I cannot find notes at this time.
olson-dan commentedon Mar 15, 2022
Ran into this today as well, let me just echo that it's pretty unfortunate that using
--manifest-pathproduces a different and potentially incorrect build depending on where it's invoked from. I'd prefer if config location started in the directory of the manifest than a new config option.Potentially this might not be breaking, because anyone depending on the current behavior would have to be building from the root of the project anyway.
lilyball commentedon Mar 17, 2022
At this point, I think that the current behavior of
--manifest-pathis actually correct. The.cargo/config.tomlfile controls the behavior of cargo itself, it's not crate configuration, and so the location I invoke cargo from should be what determines how to find the cargo config. Having a separate-C <DIR>flag solves this. Especially the part about toolchain overrides (e.g.rust-toolchain.yaml) as that is explicitly based on your current path.compenguy commentedon Jul 26, 2022
This is contrary to the cargo config documentation, which says:
the per-package .cargo/config.toml checked into version control is being ignored when built via
--manifest-path, unless the cwd is currently somewhere within the package directory tree, but the primary use case for--manifest-pathis to make build independent of cwd. This is either a cargo bug, or a cargo documentation bug, take your pick, but my vote is for cargo bug.epage commentedon Jul 26, 2022
btw #2930 is the issue about the config being relative to CWD rather than
--manifest-path. This issue is more about acknowledging things as they currently are and providing a mechanism for dealing with itI could see there being some minor wording tweaks to the documentation. My guess is its written assuming auto-discovery of the manifest in which case, it is correct. That assumption should be made more clear though.
Set cargo cwd to manifest dir, workaround for cargo issue 10098
Add '--directory,-C' flag for changing current dir before build
Add '--directory,-C' flag for changing current dir before build
Add '--directory,-C' flag for changing current dir before build
weihanglo commentedon Jan 27, 2023
Related issue:
23 remaining items
weihanglo commentedon Aug 5, 2026
@ChrisDenton For option 4, those surprises could lead to more issues being filed against
rust-lang/rustuprepo, even though-Cis a Cargo flag. We also want to make sure t-rustup is fully aware of and aligned with this option, since it affects rustup's user experience, not just Cargo.ChrisDenton commentedon Aug 5, 2026
For sure, it's a least worst option rather than a perfect solution. I think documenting this case will help. Maybe cargo could also warn if a
rust-toolchain.tomlis present but I fear that might be too noisy.But this is all hypothetical at this point, right? We don't really have a good way to gauge how this will play out if few people are using it atm?
epage commentedon Aug 5, 2026
Cargo generally limits its warnings to when a user has a reasonable way to turn it off. We are adding a linting system but this would be outside of that.
This would also have false positives because the file could lead to the same result.
We also wouldn't know about config overrides.
rami3l commentedon Aug 10, 2026
@weihanglo I still feel strange about this: it feels like either rustup or cargo needs to intercept this flag, but not both, since the behavior of both would rely on the current working directory (specifically, in rustup, this would influence directory overrides via both
rust-toolchain.tomlandrustup override set).Once
cdhas been performed it should influence both, so I think it probably should be arustupfeature rather than acargoone, meaningrustupwould take-Calongside+toolchain(taking the option 1 in #10098 (comment)) andcdbefore doing anything else.However, considering the fact that people might be using
cargowithoutrustup, there might still be a use case forcargo -C.Thus, we may end up with both tools supporting this option, with
cargo -Cbeing rarely used by the user. In the end I doubt whether that would be the best way forward.djc commentedon Aug 10, 2026
I'm not a fan of the plan of supporting
-Cand just breaking people who rely onrust-toolchain.toml.I have wanted this feature many times, but I'd rather come up with a better plan to support it well instead of having an implementation that breaks a bunch of expectations.
ChrisDenton commentedon Aug 10, 2026
I think if we want to switch
rust-toolchain.tomlvia the command line then we need to properly support this in rustup itself.djc commentedon Aug 10, 2026
Yup. Maybe we could communicate whether/how we changed the current working dir to Cargo via an environment variable?
rami3l commentedon Aug 10, 2026
@djc That'd make perfect sense to me, but I think the main question would be how to capture the user’s intent in rustup.
ChrisDenton commentedon Aug 10, 2026
In any case we probably should take a moment to explorer the design space on the rustup side and then come back to Cargo.
djc commentedon Aug 11, 2026
I don't see many downsides to doing so in this issue, where everyone can keep track of what's going on?
Here's my straw man proposal:
If rustup in proxy mode sees an invocation of
cargowith a-Coption passed in, we change the working dir for the child process and setRUSTUP_SET_CWDcontaining the path that we set in the child's environment.rami3l commentedon Aug 11, 2026
@djc I'm not sure about this, considering the fact that rustup fully delegates the resolution of
RUSTUP_SET_CWDto cargo will cause the inverse case scenario compared the one proposed above (wherecargosupports-Cbutrustupis not informed): nowrustupwill recognize the new CWD butcargomay or may not act accordingly, depending on how recent it is.djc commentedon Aug 11, 2026
If we still pass
-Con to Cargo as well (which I didn't articulate in my previous message), it would make older Cargo fail, while newer Cargo can act accordingly. Seems okay?