Typically the audio file gets updated when cover art is added or changed because the path to the cover art file is stored in the audio file as metadata. However the cover art path is also stored in MC's database, so also being in the audio file may not be necessary.
If no audio file updating is desired, MC has a master switch to enable or disable "update tags when file info changes". But disabling prevents storing in audio files most database field values (some posts suggest it is not 100% control of updating, perhaps old news). Because this is essentially all or nothing, usually disabling is not desirable.
More useful is MC's field-level control of the same action. Check box "Save in file tags (when possible)" is probably what you need; it is available for most MC fields. Select Options > Library & Folders > Manage Library Fields.
To control storing of cover art path, scroll to field "Image File". Uncheck "Save in file tags (when possible)". If it is working properly, this should do what you desire.
Note that various other things can cause file updating, including database fields MC updates on its own. I didn't want my backup systems to be processing files that got changed for no reason that matters. So, some time ago I scrolled the Library Fields list and unchecked data I don't want stored in the audio files (or don't care about at all). For instance, I don't allow updating metadata of Number (of) Plays, Last Played, and similar info. Because other users might want the opposite, this level of control is wonderful.
For instance, in my audio library (and also my photos library) I need maximum flexibility in where and how files are used. I want each file to contain as much self-descriptive metadata as possible so the file is self-contained. I use MC's database to manage and use the files, but it does not "own" them. The files are self-contained so I can easily use them and their metadata in non-MC situations.
In-file metadata is also a safety net. More than a few times in 15 years of MC I've been "saved" by being able to read key metadata from audio and image files back into MC's database.
Another example: I used to store cover art separately, to keep music files (slightly) smaller. But when music files were then used on different computers and/or places, it was a pain (or impossible) to also bring along the cover art collection and store it at the proper path. Tired of often being image-less, I switched to storing cover art in the music files, a one-time task for MC. A side benefit was giving each track a distinct picture, fun to choose what best goes with the track. And it was helpful to break the connection between track image and album title because much of my music library is NOT tied to albums.