Wow, someone can skim Wikipedia.
Actually, that was from memory. I didn't bother with Wikipedia, because it's pretty obvious that one of the prime uses of a codec is to decode -- why else would people download codec packs to help or solve playback issues? You could think of a codec as being something like a crypto plugin or device. It encodes and decodes -- doing one w/o the other is not very useful. That doesn't mean you can't produce SW that only does one.
Another example: compression. Nearly all compression SW goes both ways with a glaring exception: 'rar'. There the author wants to keep the encoder proprietary so they can keep making money off of it,
but the fact that nearly all compression SW does both is so much assumed, that people only talk about 'compression' (the encode side) algorithms. It's implicitly assumed that decoding is also part of the SW.
Audio and Video codecs are the same. They default to doing both, but owners of patents may make the availability of one direction different, like charging different prices for one but not the other. Example H.264 -- free to end users, but commercial use gets charged -- like all HW-BR players would have to have to have a license in the US. They have very specific rules as for what gets charged for and who pays (now that fact I did check on Wikipedia).
I'm not quite sure that is correct, I don't know of any media codec that both encodes and decodes. The two are separate and codecs are specialised for one or the other, not both.
As an example, LAME is used to encode MP3, but it is unable to be used to play back or decode MP3.
I know that's wrong. The code has a build-time switch to include decoding or not -- and the build docs say that doing that was for patent purposes where in some countries, playback was charged patent royalties. FLAC does both as well. You can find specific examples where the codec is incomplete, but that almost always due to patent and or $$ issues.