No, IoC containers and constructors don't violate the Open/Closed Principle.
If you need to add a new dependency to your class the Open/Closed way to do it would be to create a new class which inherits from the old one and has a new constructor with the new dependency, overriding methods where required.
If you orgional class is "Open" for extension then this should be possible.
Your IoC Container in your app meanwhile requires no extension of its functionality in order to register the new class rather than the old. So the Open Closed principle does not apply at all
Your app itself presumably can happily consume the new class as its a sub class of the original and injected via IoC so again the principle doesn't apply.
If you find that you are unable to subclass your original class and add the dependency and required functionality, and that you need to change its code to make that extra functionality work. Then your original class has failed the open/closed test.
However, these days I imagine everyone is using Interfaces rather than base classes. So you avoid a lot of these issues.
Edit. re: what about the root class in the app?
Technically you have the same option with your app's main class, ie sub class and alter the internal registration. Just because you are using an IoC Container, doesn't mean you can't override your setup function, remove and add registrations or make your class open to extension in other ways.
But at this level it would make no sense to do so. Unless you app is a plugin or some such, no other code will consume it, there isn't any downside to simply changing the code in the root class.