Errors when running Bevy hotpatching example: Missing rustc capture and Missing rustc args for replay

[MetaflameDragon]

Problem

I tried to run Bevy's hotpatching_systems example (with --hot-patch). The build runs okay, but subsequent hot patching shows the following errors:

On 1.100 (nightly), the program fails to start with Missing rustc capture.

On 1.98.1 (stable), the program launches, but making a change and triggering a hot patch errors with Missing rustc args for replay: auto_register_static. (In this case, I tried editing the text color and text string in the example project.)

I believe these issues may have a related root cause, so I'm reporting them together.

Steps To Reproduce

• Pull the Bevy repo (git clone https://github.com/bevyengine/bevy, I used the latest dev branch)
• Run with dx serve --hot-patch --example hotpatching_systems --features hotpatching
• The entire build runs without issue
• On nightly 1.100, when dx tries to start the program, it fails with Missing rustc capture
• On stable 1.98.1, the program starts, but hot-patches fail with Missing rustc args for replay: auto_register_static
• Triggering a full rebuild or re-running dx serve errors the same way

Expected behavior

The example should start/hot-patch as expected.

Environment:

• Dioxus version: dioxus 0.7.10 (57d6794)
• Rust version: rustc 1.98.1 (48a229cea 2026-09-01); rustc 1.100.0-nightly (0ed41eb41 2026-09-04)
• OS info: Windows 11
• App platform: Desktop

More details & observations

• cargo clean did not help
• In .captured-args, the 1.98.1 build had a file matching the tip crate called hotpatching_systems.bin.json, but the 1.100 build did not. Could this be why the nightly build failed to start?
• Both builds also had .captured-args files for a bunch of bevy-* crates, but nothing else (including auto_register_static, as per the rustc args replay error).
• I tried dx serve --hot-patch on Rust 1.100 on another small project of mine that uses egui. This worked and hot-patched without issue. The tip crate {crate}.bin.json was also present in .captured-args (but nothing else).
• Could this somehow be related to running an --example with hot patching? I also remember that Cargo had some notable changes in 1.100, could this be somehow related?

[MetaflameDragon]

I've reproduced the issue on a trivial Hello World Bevy project.

When building the following on Rust 1.100 (nightly), starting the program fails with Missing rustc capture.

use bevy::prelude::*;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_systems(Update, hello_world_system)
        .run();
}

fn hello_world_system() {
    println!("hello world!");
}

An abbreviated version of my Cargo.toml:

[dependencies]
bevy = { version = "0.19", features = ["hotpatching"] }

[profile.dev]
opt-level = 1

[profile.dev.package."*"]
opt-level = 2

My .cargo/config.toml is commented out, so none of those overrides should be in effect. Notably, after building, the subdirectory in .capture-args is completely empty (there's bevy_test_project-x86_64-pc-windows-msvc-desktop-dev-1e9f355ee8875b89 but it has no files).

Setting the tip crate's opt-level = 0 did not fix it, neither did cargo clean & a full rebuild.

The same project with bevy removed/commented out (so no deps at all other than std), a simple println!("Hello world"), builds and runs fine (did not test hot patching in action, just that it runs under dx serve --hot-patch).

I'm unsure if this is more of a Bevy bug (since they want to support hot patching) or a Dioxus bug (because it doesn't capture the binary/library rustc args), but I hope these findings are helpful at least.

[chipnertkj]

Interestingly enough, I also ran into this while trying to integrate subsecond with my own library, testing in a binary, while running rustc 1.100.0-nightly (8925ea358 2026-08-20). I am unaware of anything in particular I did to affect .capture-args, but my project is in a fairly dense Cargo workspace.

Update: I additionally tried checking against my build.rs configuration and lib.rs presence in tip crate affecting this, but it was adding a dependency on a crate with a large dependency tree (my library) that would cause the error to show up. Linker capture generally did work (objects for the tip crate did show up in link_args.json), but rustc capture did not (no (tip).bin.json). dx saw a linked tip binary path, tried to fat-link / set up hotpatch using tip rustc args, found none, and this resulted in an error. Capture still contained *.bin.json files for build scripts for the tip crate.