No, it actually does not. It just hides the fundamental problem.
Making the class static really solves the problem of having to pass an instance of ItemManager everywhere.
The reason that "having to pass it everywhere" is a problem is not because you're cluttering up function parameter lists with an extra parameter. That's a bit ugly, sure, but it's not the serious issue. The serious issue is that "everywhere" depends on this interface, which is a symptom of a poor or lazy design. Passing interfaces around via function parameters is actually advantageous in that respect because it makes the dependencies on your interface (the item manager in this case) very explicit, so you can see when you have way too many of them and can focus instead on eliminating those dependencies entirely instead of hiding them by making the interface globally-accessible.
To solve this problem in a better fashion, you need to analyze every dependent interface -- everywhere you "need" to pass the ItemManager -- and determine why that interface actually needs it and if/how you can eliminate it. Chances are very good you can -- why don't you try listing some of the places you currently require the ItemManager and what they do with it.
Static classes can still have static constructors. For now you can do your item initialization there, although in the longer term you should migrate to a data-driven approach where you item data is stored in a file (perhaps XML or JSON, they are simple places to start) and you read it in to the item manager at runtime. Then you can alter your item data without having to rebuild your game.
But since static classes can't have a constructor: Where should I put the initializing of all the items then?
Also, thus far this interface does not do anything I'd consider "management" at all. It just holds on to a bunch of data. The term "manager" is a vague/azy and consequently makes for a poor choice in interface names. I'd instead call this interface and ItemCollection or ItemDatabase, depending on the eventual operations you support with it.
This is weird because it implies the item ID corresponds to the position in the items list, which is brittle and non-scalable, because the order in which you add the items must also correspond with the IDs you've assigned items, making for two places where the code must change if you re-order or tweak the IDs of items (especially since you define the ID with the item instead of letting the collection itself define the ID). Better instead to use a Dictionary, probably, as another user has already suggested. The list as a mechanism for storing this things internally doesn't buy you much at all.
Other than that, I hate to refer to items.items[itemID], but that is mainly just because it looks terrible.
You can clean up the interface by either adding an explicit FindItemById() method to the item collection, or using an indexerin the item collection, which would let you access items via itemCollection[itemId]. Then you don't need to expose the item storage directly, which is good because if you do expose the item storage directly, client code can manipulate it (adding and removing) and thus destabilize your interface.