It's detected as a trojan, which it's not. It's just a tool that does something that CAN be used maliciously but is NOT in this case. I don't mind that this type of thing is detected because normally one would not want this to be happening but this is a TOOL that I need to use for legitimate reasons. It's a PowerShell script that just has .txt as a file extension.
There is no "existing exclusion". Restoring from quarantine doesn't create an exclusion as I mentioned (that option is grayed out) and I CANNOT CREATE THE EXCLUSION EXCEPT BY MANUALLY TYPING THE PATH AND FILENAME. What are you not getting about this? Stop reciting what's in your response scripts and actually read. My complaint is that I can't just follow the steps to select the file and add an exclusion without MANUALLY TYPING THE PATH AND FILENAME. It's impossible to add an exclusion using the obvious method of selecting the file after browsing for it, the method that ESET's own instructions give, because selecting the file immediately deletes it so I can't press OK to have the file's path and name put into the exclusion path field. It has to be done manually, and claiming that it's a two-step process "for security" is ridiculous and insulting (not to mention it doesn't work the way you said). It takes plenty of effort to even get to the exclusions, and what's the point of even having a "browse" option if you can't actually use it? Why prevent me from simply adding the exclusion in the same step as restoring it from Quarantine? And excluding the entire folder isn't a good idea when it's just a temp folder with a bunch of other unrelated files, and you shouldn't blindly recommend that to users without information about what the folder contains.