Bevy uses wrong asset folder path when running from exe

[Saratii]

Bevy version and features

0.17.3

[Optional] Relevant system information

windows 11

What you did

Ran bevy from executable instead of cargo run while in project root.

What went wrong

I expected it to find the assets folder based on the root of the project.
It instead checked for the assets folder inside of /target/release

If there is a config for this I would be happy to hear about it but I consider this a failure because it should work by default for such a simple action.

C:\Programming\project> .\target\release\project.exe
...
2025-12-13T06:55:22.794003Z ERROR bevy_asset::server: Path not found: C:\Programming\project\target\release\assets\texture.ktx2
...

[Saratii]

I know I can change the default asset path but the fact its not dynamic makes it difficult to profile apps because the exe launches from weird locations.

[andriyDev]

This is intentional. Here's the code:

bevy/crates/bevy_asset/src/io/file/mod.rs

Line 19 in 9c58976

pub(crate) fn get_base_path() -> PathBuf {

Bevy intentionally looks for the asset folder next to the executable if its not being run inside cargo. This way, no matter where you call the command from, it accesses the assets at a "stable" location. If you really want to mess with the asset path, you can either use the BEVY_ASSET_ROOT environment variable, or set the asset path in the AssetPlugin.

Edit: to clarify, the expectation here is that if you're directly running the executable, you're likely getting ready to publish, so reading assets near the executable makes sense!

[SludgePhD]

This is pretty surprising behavior. Normally, you would expect manually running the executable to do the same thing cargo run does. This should, at the very least, be properly documented.

[perry-blueberry]

Another thing maybe related is that when running in a debugger with default vscode settings it doesn't find the assets. Don't know of a good solution for this.

[Saratii]

This cannot be intended.

[andriyDev]

This is pretty surprising behavior. Normally, you would expect manually running the executable to do the same thing cargo run does. This should, at the very least, be properly documented.

We can't reliably do what cargo run does though. For example if we didn't use the executable location and instead just use pwd, if you cd somewhere else in your project (not at the root), then this will also break. Using the executable location makes it more reliable for published binaries, which is going to be the most common use of running the binary manually I think?

I'm also not sure where we should document this. Perhaps in the bevy book when that's ready? I don't know where I would look to find this information.

Another thing maybe related is that when running in a debugger with default vscode settings it doesn't find the assets. Don't know of a good solution for this.

Interesting! I wonder if the debugger runs the binary with an environment variable we can look for? Worth investigating!

This cannot be intended.

Please explain why. What workflow does it break?

For an example of when this is desirable, imagine you copy the binary (and the assets) to ~/some/folder/to/my_game. If your current directory were ~, and you tried to run it with some/folder/to/my_game, it would look for assets in some/folder/to/assets which is desirable - we can now run our Bevy app from anywhere and it'll work. If we instead used the pwd to search for the assets, you could only run the app from a very specific pwd otherwise it won't find the assets.

[Saratii]

With the current implementation, I am required to use https://docs.rs/bevy/latest/bevy/asset/enum.UnapprovedPathMode.html when I need to run profiling tools on the binary. According to its documentation, it is highly not recommended.

[SludgePhD]

Perhaps asset folders should be marked with a .bevy_assets file (if there isn't some file like that already)? Then the default behavior could be to search upwards from the executable's path until an asset folder is found.

[andriyDev]

With the current implementation, I am required to use https://docs.rs/bevy/latest/bevy/asset/enum.UnapprovedPathMode.html when I need to run profiling tools on the binary. According to its documentation, it is highly not recommended.

@Saratii can you please describe what situation you're in that you need this? Maybe I'm not understanding the practical situation where this is a problem. From my perspective, it seems to be the very niche case where you've built the binary and are testing that it will works without cargo - rather than packaging them up and testing them then? I'd like to understand if there's another situation!

[andriyDev]

Perhaps asset folders should be marked with a .bevy_assets file (if there isn't some file like that already)? Then the default behavior could be to search upwards from the executable's path until an asset folder is found.

@SludgePhD this is a potential solution, but I'm not excited about it, especially since we wouldn't be looking for something above the executable, but above and in the assets folder. This kind of search makes me a little worried about complexity of deciding on where to read assets - the current solution already kinda sucks but it's clear some trade-offs were considered.

[andriyDev]

Oh also @Saratii, there's a workaround: you can explicitly set the path to the assets folder in AssetPlugin to std::env::current_dir() + "assets". Then you get the behavior you want. It probably won't do what you want when published (though it still might?) but that's the trade-off.