I think you may already be doing this in close to the best way, but here’s my breakdown.
Your disk drive storage is where the binary data of the asset is stored. You find that file with the asset’s file path. You’ve got RAM, where the asset’s binary is copied (loaded) into for active manipulation.
When you use your tool, you’ve got some editor class. With the editor class, you can use the file path the AssetDatabase to load (copy) the binary data from storage into ram.
At a certain point you either need to hard code the file path of the scriptable object, a path to a config file that has that file path you want, or you need to search for the asset you want.
You can search for the asset with something like AssetDatabase.FindAssets(“t:MyScriptableObjectConfig”, null); which will give you an array that contains a single GUID, assuming you only have one instance of this config asset type in your asset folder.
From the GUID, you can use AssetDatabase to get the filepath. Once you have a file path you want to save, you can either store it in some other general editor config file, or you can use EditorPrefs (like player prefs, but for the editor) to save the path with a key that is… hard coded into your script.
I suggest saving the GUID, not the path, to Editor prefs, in case you move the asset. Use AssetDatabase to get the path every time you load your asset into RAM.
If the editor is closed, you will have to load the asset into RAM again, but you won’t have to search your entire AssetDatabase if you have already saved the GUID to EditorPrefs.
Once your asset is loaded, assign it to a static variable in your editor script so you don’t have to load it again until unity is closed. Just make sure you don’t have a lot of assets referenced in this scriptable object, or else all those objects will just be sitting in memory, referenced via that static variable.