There are different approaches that might yield the desired result, depending on what kind of person your manager is:
Ask for clarification
Ask him why renaming the class is nessecary, what advantages it would have for the future of the code and the product, why it cannot stay the way it is.
If his answer is "because I said so", give him your reasons and justifications why the code is the way it is.
- It's always been like that
- But I like it this way better
- It's best practice to call it "whatever"
- It's called that name in virtually every software, manual or school book available (the current name is conform to people's expectations)
- It's a representation of a "whatever thing" that is called "whatever thing" in all of our documentations, so the class should be called "WhateverThing" as well
- It was decided by the whole team
Ask him to follow the rules
Things like renamings are usually decided during code reviews. If the respective code has been reviewed, the current name was agreed on by several team members.
If your manager is not currently reviewing your code, ask him to create an issue or change request in your bug tracking system. These have the tendency to be delayed forever.
If deadlines are always approaching too fast and there is never time for a breather, ask him what the benefits of his change would be.
Any refactoring costs time. That doesn't mean you shouldn't do refactorings at all, but if you do one, the benefit for future developments should overwheight the time you invest into the refactoring.
If one name is as good as the other, changing it would be wasted time. If one name improves the understandability of the code, it would be a beneficial refactoring.
Tell him to stick to his role
I do not advice this one unless you have a very good standing in your job and your manager is not the type to take criticism personally.
In my experiences, micro-managers often cannot keep up with the actual managing tasks they're supposed to do because they're micro-managing too much. You could tell him (friendly) that he would help you more if he took care of his tasks while letting you take care of your tasks.
A more unfriendly (and risky!) approach is to tell him that as a manager it's not his job to code anymore.
Again: I do not advice this! Use this approach at your own risk (and involve your brain).