OK, I see! 
My first question would be, why does the automation doesn’t handle a manual override already? If the automation is already monitoring the state of the cover(s), it should know, that someone has taken over control. 
That’s why I’m asking.
Btw. for exactly this use case we do have a fantastic integration and a blueprint here in this very forum. There already is a “manual override” included! Take a look in this thread:
It started as a blueprint, which is still available, and ended in an integration, that is really amazing! Just saying, but there was already someone who invented that wheel. 
I’d recommend to take a look at least at the blueprint, it might give you some ideas.
But that won’t solve your initial question, so let’s go on with that. If it where me, I’d work with an adjustable timer. You could start it with a button press in the frontend, ideally you would change the already existing automation to check for that timer.
But if that automation is “not changeable”, you could also write an automation, that reacts on the timer running. With the beginning of that timer, the automation would disable the other automation and enable it back after the timer finishes. But I wouldn’t go that route tbh, it’s not really a good idea to enable/disable automations from within other automations. Better to change existing automations to react on different states.
But that’s all theory, let me know, which way you want to go, integration, blueprint or own automations, and we can figure out how to solve this.
If it were me, I’d try the integration first, than the blueprint, and then the change of the existing automation. If all that doesn’t work like I want it to, I’d take a seperate automation, but really only as a last resort.