This is definitely an XY Problem. You’re attempting to avoid transparency modifications of your pseudotools by not having them parented to the character, which is a terrible workaround.
If you’re looking to have a pseudotool not adhere to the visibility that’s gained from the CameraModule, you will have to create a blacklist feature. Naturally, this will also require forking of the CameraModule if such implementations don’t already exist (which I believe they do not).
There are three ways I know how to get this done:
CollectionService: You can fork the CameraModule and include a line where any parts tagged with a certain tag will ignore transparency modifications done by the script. From there, you can just tag the parts and everything will be taken care of you by the modified CameraModule.
Internal Blacklist: Similar to CollectionService, except instead you can make full use of CameraModule (and furthermore the fact that its a ModuleScript) by having it expose transparency blacklist functions upon require.
External Control: You can have an external LocalScript that uses BindToRenderStep on a priority higher than the one used in CameraModule, which will set the LocalTransparencyModifier of the descendants of the pseudotool to 0. I generally wouldn’t do this, since I can fork the CameraModule itself and append relevant functionality in there.
As for animations acting like “static welds” when they aren’t parented to the character, this is because you animated the pseudotool while it was in the character (most likely). Animations adhere to a very strict object hierarchy - naming convention and ancestry/descendants are important.
Animations are simply modifications of Motor6D Transform properties. That being said, animations cannot suddenly hold references to parts that exist in your game or make any assumptions - that is why they need explicit naming conventions. They need a pathway to the Motor6D by name before they can change the Transform property. Simply changing the ancestor of the pseudotool makes all the difference in what happens when you run the animation.
Overall, I think it’s messier to move the pseudotool out of the character to void transparency, when you can have the pseudotool in the character and opt to create a blacklist feature.