fix(protonmail): bump defaultAppVersion to solve CAPTCHA

[thisago]

x-pm-appversion being "Other" (and absence) triggers anti-bot.
Solution: Use the exact ID from the webapp. Login works now.

This PR simply changes the default constant, as the code is correct. And
sice there's the flag -app-version, this new string can be used in
builds without this change also, see below.

State before fix (known bug):

$ hydroxide auth thisago
Password:
2026/07/28 22:18:09 request failed: POST https://mail.proton.me/api/auth: [9001] For security reasons, please complete CAPTCHA. If you can't pass it, please try updating your app or contact us here: https://proton.me/support/appeal-abuse
2026/07/28 22:18:09 [9001] For security reasons, please complete CAPTCHA. If you can't pass it, please try updating your app or contact us here: https://proton.me/support/appeal-abuse

With the custom -app-version, before this bump):

$ guix shell hydroxide -- hydroxide -app-version 'web-mail@5.0.124.7' auth thisago
Password:
2FA TOTP code: ...
Bridge password: ...

After this fix:

$ ~/go/bin/hydroxide auth thisago
Password:
2FA TOTP code: ...
Bridge password: ...

Closes: #235; Closes #328

[Stefanuk12]

I'm trying to use this PR and I'm still having the same issue. I made sure to use the latest Proton version number. Am I doing something wrong?

[thisago]

@Stefanuk12 Can you provide more context?

FWIW my account has:

• "Mail Plus" plan
• 2FA TOTP enabled

I didn't test without these settings, I can't tell it's needed or not to work.

For proof-test, I just retried now, still working:

• 0.2.31: https://asciinema.org/a/qxozxdHpfuSBKlnf
• this build: https://asciinema.org/a/681CtdVzZbZGn4uW

[Patrick-Ze]

It appears to be related to the risk control level of the account itself. I have two accounts:

Account	Plan	TOTP	CAPTCHA required in web	hydroxide without -app-version	hydroxide with -app-version
account 1	free	yes	no	login success	login success
account 2	free	yes	yes	9001	9001

[emersion]

We used to set the app version to the web client's, but this resulted in some users being unable to log in: #254

The constant version chase is also cumbersome, and it's not a reliable way to fix the CAPTCHA issue.

[Stefanuk12]

While searching for a solution, I found this fork which worked for me. It provides a local server for a human to solve manually.

An ideal solution would be to serve a local server (like the fork) AND an API to fetch the CAPTCHA metadata so you can use an automated service to solve it as well.

EXTRA CONTEXT

My account is a free account with the 500 MB limit. The account has existed for years now and has been active for several months. The account also has TOTP and a passkey setup. Not sure why the risk level of my account is higher. It might be since I mainly login via Linux and I use the Helium browser.

[thisago]

It appears to be related to the risk control level of the account itself. I have two accounts:
[...]

Interesting, my account indeed doesn't require captcha in browser login.

We used to set the app version to the web client's, but this resulted in some users being unable to log in: #254

The constant version chase is also cumbersome, and it's not a reliable way to fix the CAPTCHA issue.

Thanks for context, didn't find this issue earlier. I agree, bumping constant is not optimal. An alternative may be documenting this case for new users try with the custom app version. I can add it to README if you agree.

An ideal solution would be to serve a local server (like the fork) AND an API to fetch the CAPTCHA metadata so you can use an automated service to solve it as well.

Agreed, sorry for marking this PR as solving the open issues as it doesn't fixes all cases.

[emersion]

Presenting the CAPTCHA to the user sounds fine to me, but to be clear, I would not merge any patch to automatically solve the CATPCHA since that would bypass ProtonMail requirements.