fix: Auto-detect and recover from stale cargo cache (integrated)

[jryanhaber]

Fixes #9397

Intent

The intent of this PR is to eliminate manual intervention when cargo's incremental compilation cache references outdated struct definitions, by integrating stale cache detection directly into the existing build workflow rather than requiring developers to adopt a new command.

Current UX Flow (Broken)

1. Developer pulls changes or modifies struct fields
2. Developer runs just build (or cargo build)
3. Build fails with error[E0609]: no field X on type Y
4. Developer must manually diagnose as stale cache
5. Developer must manually run cargo clean -p affected-crate
6. Developer must manually retry build

Target UX Flow (Fixed)

1. Developer pulls changes or modifies struct fields
2. Developer runs just build (same command as always)
3. Build detects 'no field...on type' error automatically
4. Build extracts affected crate and cleans it automatically
5. Build retries and succeeds automatically
6. Developer continues without ever knowing there was an issue

Implementation

• Integrated into existing just build recipe (no new commands to learn)
• Wraps cargo build with error detection and auto-recovery
• Extracts crate name from compiler error (e.g., codex_tui from codex_tui::Cli)
• Converts snake_case to kebab-case for cargo clean compatibility
• Falls back to full cargo clean if crate extraction fails
• Passes through all build arguments (--release, -p, etc.)

Why This Approach

Developers shouldn't need to learn a new command or remember when to use it. The fix is transparent - they use the same just build command they already know, and stale cache issues are automatically detected and resolved.

Testing

Manual reproduction test:

cd codex-rs

# 1. Add temporary field to tui/src/cli.rs
#    pub test_field: bool,

# 2. Build successfully
just build --bin codex

# 3. Remove the field, clean cli only, add field back
cargo clean -p codex-cli

# 4. Build with just (auto-recovers)
just build --bin codex
# Detects error, cleans codex-tui, succeeds transparently

Checklist

• Ran just fmt
• Tested and working
• Integrated into existing workflow (no new commands)
• Atomic commit (compiles successfully)
• Links to bug report (Stale incremental cache causes 'no field' compilation errors #9397)

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 728eea6cec

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid cleaning non-package module names from rustc errors

When the compiler reports a missing field on a type in the current crate (e.g., crate::Cli or cli::Cli), the regex above captures the first path segment (crate/cli) and cargo clean -p is invoked with that value. cargo clean --help shows -p/--package expects a package spec, so module names like crate (or cli) are not valid package IDs in this repo (packages are codex-*), which makes cargo clean -p fail and, with set -e, exits before the original compiler error is shown or the build is retried. This makes ordinary compile errors surface as a clean failure instead of the real error. Consider validating the extracted name against workspace package IDs (or skipping -p when it’s crate/self/module) and falling back to cargo clean only when the package lookup succeeds.

Useful? React with 👍 / 👎.

[etraut-openai]

@jryanhaber, thanks for the contribution. I left you some questions in the bug report.