`cargo metadata` `workspace_default_members` behaves differently when executed within a member package

[tonywu6]

Problem

When executed within the directory of a member package, cargo metadata returns a workspace_default_members array that only contains the member package itself, as opposed to the full list of resolved members as specified by the workspace manifest.

Steps

1. Create a minimal virtual manifest:

   [workspace]
   resolver = "2"

2. cargo new package1
3. cargo new package2
4. cd package1
5. cargo metadata --format-version 1 | jq '.workspace_default_members' (Using jq for readability)

[
  "path+file:///.../package1#0.1.0"
] // expected both packages

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.94.0 (85eff7c80 2026-01-15)
release: 1.94.0
commit-hash: 85eff7c80277b57f78b11e28d14154ab12fcf643
commit-date: 2026-01-15
host: aarch64-apple-darwin
libgit2: 1.9.2 (sys:0.20.3 vendored)
libcurl: 8.7.1 (sys:0.4.84+curl-8.17.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 3.5.4 30 Sep 2025
os: Mac OS 15.7.5 [64-bit]

[epage]

Looking at the source, it appears cargo metadata is not reporting the literal workspace.default_members (with a fallback to the default value) but is providing what we use internally: the default members for the current invocation which gives priority to the current package if we running inside of another package than the workspace root

cargo/src/cargo/core/workspace.rs

Lines 858 to 882 in 7a6c83c

	let Some(workspace_config) = self.load_workspace_config()? else {
	debug!("find_members - only me as a member");
	self.members.push(self.current_manifest.clone());
	self.default_members.push(self.current_manifest.clone());
	if let Ok(pkg) = self.current() {
	let id = pkg.package_id();
	self.member_ids.insert(id);
	}
	return Ok(());
	};
	// self.root_manifest must be Some to have retrieved workspace_config
	let root_manifest_path = self.root_manifest.clone().unwrap();
	let members_paths = workspace_config
	.members_paths(workspace_config.members.as_deref().unwrap_or_default())?;
	let default_members_paths = if root_manifest_path == self.current_manifest {
	if let Some(ref default) = workspace_config.default_members {
	Some(workspace_config.members_paths(default)?)
	} else {
	None
	}
	} else {
	None
	};

Original issue: #8033

Original PR: #11978

I'm not seeing any explicit discussion of this. The closest is at #8033 (comment)

Cargo extensions and dev tools will want to emulate cargo, like having options like --manifest-path, --workspace, --package, etc. There are tools to do this like clap_cargo + cargo_metadata which makes use of cargo metadata. This allows cargo-foo bar to operate on all workspace default members just like cargo check / build / test / etc.

Official documentation

    /* Array of default members of the workspace.
       Each entry is the Package ID for the package.
    */
    "workspace_default_members": [
        "file:///path/to/my-package#0.1.0",
    ],

[epage]

CC @sunshowers

[verysleepylemon]

The discrepancy comes from how Cargo determines "default members" depending on where you run the command.

Why they differ:

When you run cargo metadata from inside a workspace member's directory, Cargo sets the current package as the default member. When you pass --manifest-path /abs/path/to/workspace/Cargo.toml from outside the workspace, Cargo uses the workspace root Cargo.toml's [workspace] default-members field — or, if that's absent, it falls back to all workspace members.

The reliable workaround is to cd into the workspace root first:

# Instead of this (gives inconsistent workspace_default_members):
cargo metadata --no-deps --manifest-path /path/to/workspace/Cargo.toml

# Do this:
cargo metadata --no-deps --manifest-path /path/to/workspace/Cargo.toml \
  --format-version 1
# OR change cwd to the workspace root:
(cd /path/to/workspace && cargo metadata --no-deps)

Or explicitly set default-members in your Cargo.toml:

[workspace]
members = ["crate-a", "crate-b", "crate-c"]
default-members = ["crate-a"]   # explicit — then --manifest-path produces consistent results

When default-members is explicitly listed, cargo metadata respects it regardless of the current directory or whether --manifest-path was used.

Root cause in Cargo internals: GlobalContext::current_dir() is used to resolve virtual workspace default members when default-members is absent. When invoked via --manifest-path, the current directory isn't the workspace root, so the inference differs. This is tracked as a consistency issue — the expected behaviour is that workspace_default_members should always equal the workspace-level default-members field (or all members if absent) when --manifest-path points to the workspace root.

[weihanglo]

@verysleepylemon you have posted 3+ comments in 1 minutes without adding real values.

• Docs could clarify whether rerun-if-env-changed is needed for Cargo env (PROFILE, OPT_LEVEL, etc) #16800 (comment)
• Cargo creates ./target in workspace even when target-dir is redirected to Docker volume #16826 (comment)
• cargo metadata workspace_default_members behaves differently when executed within a member package #16834 (comment)

Going to mark them as spam. Will let mod know and ban you from the project if continue doing so.