First thing is that CAPTCHAs were designed so people could not use automation on the site. So if there was something you could do from your automation to disable the CAPTCHA or get around it then people who the site wants to keep out could use the same method to bypass the CAPTCHA.
A classic example of a safeguard with a bypass was all Microsoft products. In order to prevent people from stealing Microsoft products you have to enter a product key. Twenty years ago this was a big problem for testers at Microsoft. They would have to generate product keys every time they wanted to test the product. So Microsoft changed the code. You had to enter the product key OR 11111-11111111-11111. If you just held down the 1-key until it filled the input then pressed validate, it worked. Now they could have taken out this hack after they finished tested but by QA standards, if you modify the code, you have to retest it. Microsoft decided to just leave the backdoor in.
After a while word got out and soon everyone knew that enter 11111-11111111-11111 would unlock all Microsoft products. Now Microsoft products require a real product key.
Same sort of thing for CAPTCHAs. If there was a secret bypass that always bypass the CAPTCHA then word would get out and spam robots would soon be programmed to use the secret bypass.
The best solution I have found is that the developers could put in a piece of code that checks an environment variable or system configuration. If the variable is set then CAPTCHA gets bypassed. During testing, you would deploy the binary, configure the variable to be unset, confirm that CAPTCHA works as expected. Set the variable, confirm that CAPTCHA is bypassed. Do all your testing without worrying about the CAPTCHA.
As part of the release testing, you want to make sure all deployments to production have the variable unset so CAPTCHA will be enabled.
This way you don’t have a new binary and don’t need to test everything all over again.