Problem
refresh_assets delegates to Unity's global AssetDatabase refresh:
AssetDatabase.Refresh(ImportAssetOptions.ForceUpdate);
AssetDatabase.SaveAssets();
Unity treats ForceUpdate as a user-initiated import, so project importers and packages such as Addressables may process the resulting imports. The public name and schema suggest a harmless refresh, and the response does not report the affected assets or importer side effects.
Responsibility boundary
NexusUnity contains no Addressables dependency, repair routine, or Addressables-specific callback. The observed mass repair is owned by the parent project or another package, with refresh_assets acting as the trigger.
Evidence
Editor/nexus_bridge/routes_editor.py:172-173Editor/MCPServerMethods.Asset.cs:146-177Editor/MCPServer.Timeline.cs:135-158 provides only limited aggregate import/delete/move timeline data.Editor/nexus_bridge/schemas_editor.py:72-75, Editor/MCPServerMethods.Tools.cs:258-259, and API_REFERENCE.MD:182-188 do not explain the user-initiated import semantics.- Existing tests verify routing only, not import scope, callbacks, or affected-asset reporting.
Impact
A client can unintentionally trigger expensive or project-specific repair/rebuild work while believing it requested a read-only refresh. There is no structured way to inspect what the operation imported or changed.
Suggested direction
Document the import semantics explicitly. Consider structured post-operation reporting using the existing asset timeline/callback path, and evaluate separate options or operations for filesystem refresh, targeted import/reimport, and project-specific repair workflows. Add tests for the public contract and affected-asset reporting.
Problem
refresh_assetsdelegates to Unity's global AssetDatabase refresh:Unity treats
ForceUpdateas a user-initiated import, so project importers and packages such as Addressables may process the resulting imports. The public name and schema suggest a harmless refresh, and the response does not report the affected assets or importer side effects.Responsibility boundary
NexusUnity contains no Addressables dependency, repair routine, or Addressables-specific callback. The observed mass repair is owned by the parent project or another package, with
refresh_assetsacting as the trigger.Evidence
Editor/nexus_bridge/routes_editor.py:172-173Editor/MCPServerMethods.Asset.cs:146-177Editor/MCPServer.Timeline.cs:135-158provides only limited aggregate import/delete/move timeline data.Editor/nexus_bridge/schemas_editor.py:72-75,Editor/MCPServerMethods.Tools.cs:258-259, andAPI_REFERENCE.MD:182-188do not explain the user-initiated import semantics.Impact
A client can unintentionally trigger expensive or project-specific repair/rebuild work while believing it requested a read-only refresh. There is no structured way to inspect what the operation imported or changed.
Suggested direction
Document the import semantics explicitly. Consider structured post-operation reporting using the existing asset timeline/callback path, and evaluate separate options or operations for filesystem refresh, targeted import/reimport, and project-specific repair workflows. Add tests for the public contract and affected-asset reporting.