Cargo.lock isn't updated along with workspace.package.version in releases

[ziyao233]

What issue are you seeing?

During releasing, workspace.package.version in Cargo.toml is updated to the version number, while Cargo.lock is not1 2. This makes Cargo.lock mismatches with Cargo.toml, and when building/fetching crates with --locked argument, cargo will fail. For example,

# cargo fetch --locked
    Updating crates.io index
error: the lock file /root/new_codex/codex-rust-v0.112.0/codex-rs/Cargo.lock needs to be updated but --locked was passed to prevent this
If you want to try to generate the lock file without accessing the network, remove the --locked flag and use --offline instead.

To ensure reproducibility, distributions often make use of --locked argument3 to ensure the lock file is the same across different builds. Mismatches between Cargo.lock and Cargo.toml introduce extra maintenance burden for them.

What steps can reproduce the bug?

Download the release tarball or checkout to a release tag (similar issues present in both v0.112.0 and v0.111.0), run

cd codex-rs && cargo build --locked  

What is the expected behavior?

Crates are successfully fetched, and no error is reported.

Additional information

No response

[mvanhorn]

Analysis & Root Cause

I dug into the release pipeline to trace this bug.

The gap: The rust-release.yml workflow validates that the git tag matches workspace.package.version in codex-rs/Cargo.toml (lines 25-46), then builds binaries - but there's no step that regenerates Cargo.lock after the version bump. The rust-release-prepare.yml workflow only handles models.json updates, not version bumps.

Why it breaks: When workspace.package.version changes, all workspace members using version.workspace = true get a new version string. Cargo needs to update the lockfile to reflect this. Without a lockfile update, cargo build --locked (or cargo fetch --locked) sees a mismatch and fails - exactly the error in the report.

Evidence:

• rust-ci.yml uses sha256sum Cargo.lock for cache keys, confirming the lockfile is tracked and expected to be accurate
• No script in scripts/ or target in justfile handles lockfile regeneration during release
• No commit in recent history references lockfile updates alongside version bumps

Proposed Fix (three options, simplest first)

Option A - CI fix (1 line): Add cargo update -w to rust-release.yml after checkout, before the build step. This syncs the lockfile at build time so --locked works from the release tag's artifacts.

Option B - Commit-time fix: Add a just bump VERSION recipe to the justfile:

bump version:
    sed -i 's/^version = ".*"/version = "{{version}}"/' Cargo.toml
    cargo update -w

This ensures Cargo.lock is always committed alongside the version change.

Option C - Both: Fix at commit time AND add a CI safety net.

Happy to submit a PR for whichever approach the team prefers.