It’s possible, but it’s a bit fiddly (and really not recommended).
You can create files in the engine content folder instead of your individual project (e.g. Epic Games\4.11\Engine\Content)
then access via: view options > show engine content (in the content browser).
To make it easy to move to new releases I make a symbolic link called “SharedContent” inside that folder pointing to a directory elsewhere (complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/)
That means I just recreate the symbolic link every time I upgrade and the files are instantly accessible to the engine and all projects.
You have to be VERY careful what type of stuff you include, because each project knows nothing about the others, so it’s easy to mess up other projects creating dependency issues. I wouldn’t use it to derive classes from, because the chances are high of making a design mistake, and having to go back and change something in the shared base class. Then you might find yourself having to go through every single project that uses it, updating variables or functions. So that ends up taking up more time than you thought you’d be saving. I’m glad I made that mistake early on, on a very small scale haha.
Basically, things have to be VERY general and completely encapsulated if you want to share them safely. So I just use it for blueprint functions/macros, and content like animations and sounds, i.e. content that a lot of projects can use, but won’t be edited that much (preferably not at all). Another thing I just thought of: if you intend on changing engine version with shared content, there could always be some obscure change that makes content unreadable to other older projects, it hasn’t happened to me but it’s possible. Just another reason to avoid projects depending on shared content. Having an unreadable sound or animation file is one thing, you’d still be able to update your project and get things going again. But having an unreadable base class would really ruin your day. Good luck