On PPCG, languages are defined by their implementation. This includes any configuration files. Therefore, if you edit your local configuration files, you are essentially creating a new unpublished implementation of an existing language. Now, if you were to significantly edit your configuration files, and publish them somewhere, you have essentially created a golfing library, which is allowed (although generally disliked, but that's beside the point).
If we allow editing of configuration files, I see no reason to stop there. We can edit source code of the interpreter too! No matter what scoring method you use, it just seems to me like opening a huge can of worms. It paves the way for MetaConfigScript, makes scoring more confusing, bogs us down in even more rules, and makes testing significantly harder. So here is my proposal:
If your solution runs with any fresh install of the language you are using, your solution is valid. Otherwise, your answer is basically just a it works on my machine!.
If your solution requires one very specific install of the language you are using, this is perfectly fine, but please specify this in your answer.
I think this is a reasonable default because it keeps testing as simple as possible, and it fits with our rule of "languages are defined by their implementation". Presumably any language that might benefit from tweaking defaults would also have a way to edit that behavior inside of your solution, and however many bytes of boilerplate that takes is a reasonable byte handicap.
turtle.cfgfile, or is it like
.vimrcwhere you have to create your own? \$\endgroup\$