"A new library Assets/ folder never mounts until you restart the editor"

You add the first assets to a library that previously had only code:

• The Code/ side hotloads without a restart, as usual.
• But the new Assets/ folder stays invisible to the editor. Asset search returns nothing for anything under it, and asset_info on an absolute path inside it reports no asset.

Everything looks correct on disk (the files are there, the paths are right): the editor simply never sees them.

The editor mounts a library's Assets/ folder when it discovers the library at startup. A folder that did not exist when the editor started is never mounted, and there is no rescan or remount command and no editor API to force one.

This is not a dead file watcher. A file written into an already-mounted asset folder still indexes within seconds: the watcher on existing mounts works fine. The gap is specifically the mount step: a brand-new top-level Assets/ folder in a library was never registered as a mount point, so nothing watches it and nothing indexes it.

This is distinct from a library that isn't registered as a project at all (the case where a Libraries/* folder has no .sbproj and never becomes a library project). Here the library is already discovered and compiling: only the asset-mount side is missing, purely because the folder appeared after boot.

Restart the editor. That is the only fix: it re-runs library discovery, sees the now-existing Assets/ folder, and mounts it.

Practical rule: any change that adds the first assets to a previously asset-less library needs an editor restart before those assets are testable, even though the library's code side hotloads without one. Plan the restart into the workflow rather than debugging "missing" assets that are sitting right there on disk.

Addendum: the same gap can strand individual files inside a mounted folder

Confirmed on engine 26.07.22: the same watcher gap can also strand individual files inside an already-mounted, actively-compiling folder, and there the trigger is a missing mtime change, not folder age. A batch of source files placed by a set of merges can split three ways under one asset_compile sweep: some already indexed and compiled, some indexed but not yet compiled, and a subset that comes back No asset at '<path>', genuinely absent from the asset database, sitting in the same folder as siblings that worked fine. The absent subset shares one property: their mtime never changed since the editor process started, so no filesystem event ever told the watcher they existed.

This one is cheaper to fix than the folder case: bump the mtime on the affected files (content untouched, working tree stays clean) and they index within seconds, then compile normally. Practical rule: read asset_compile's literal error before assuming a restart is needed: No asset at means unindexed (an mtime touch fixes it), anything else means it's already indexed and the problem is downstream.

Asset mounts are established during library discovery at editor startup, and there is no runtime remount path. A restart is the only event that re-runs discovery, so it is the only way to pick up a folder that was created after the last boot. Once the folder is mounted, its watcher behaves normally and later files under it index within seconds: the restart is a one-time cost per newly-created asset folder, not per file.