Apple ID works in browser, but icloudpd login fails with -20101 after account lock

[DriessenbeeR]

Hi everyone,

I’m running into an issue with icloudpd after my Apple ID was temporarily locked due to repeated automated login attempts from a script.

Here’s my situation:

• My Apple ID was locked with error -20209 (“account locked for security reasons”)
• I reset the password via iForgot and Apple Support unlocked the account
• I can now log in successfully:
• via browser (icloud.com)
• via iPhone
• However, icloudpd authentication still fails consistently

When running:

icloudpd --username --auth-only --cookie-directory ~/.icloudpd

I always get:

code: -20101
message: "Check the account information you entered and try again."

Additional details:

• I already waited more than two week without any login attempts
• I removed ~/.icloudpd to clear old sessions
• I tried both username formats (short name and full email)
• Password is definitely correct (works elsewhere)
• No 2FA prompt appears — it fails before that

From the logs it looks like:

• /signin/init succeeds (HTTP 200)
• /signin/complete fails (HTTP 401)

So it seems Apple is rejecting API-based authentication, while normal login still works.

My question:

Has anyone experienced this before?
Is this a known Apple-side restriction (e.g. blocking programmatic logins after suspicious activity), and if so:

• Is there any way to recover from this state?
• Or is the account effectively blocked for tools like icloudpd?

Any advice or similar experiences would be highly appreciated.

Thanks a lot!

[wip58]

Take a look at issue1331.
It worked for me. Now I am testing both icloudpd and kei

[DriessenbeeR]

Hi @wip58
Thanks for the suggestion!

I took a look at issue #1331, but I think my situation is different.
In my case, the authentication fails before reaching the 2FA step. I am never prompted for a verification code.

I am using the following command:
icloudpd --username Username --auth-only --cookie-directory ~/.icloudpd
(Note: I am using the short username format without @ and . — this worked fine before.)

From the logs:

/signin/init succeeds (HTTP 200)
/signin/complete returns HTTP 401 with error -20101 ("Check the account information you entered and try again.")

Here is a sanitized excerpt of the output:
INFO Processing user: Username
DEBUG Authenticating...
iCloud Password for Username:
INFO ('Invalid email/password combination.', PyiCloudAPIResponseException('{
"serviceErrors" : [ {
"code" : "-20101",
"message" : "Check the account information you entered and try again."
} ]
} (401)'))

DEBUG request: POST /appleauth/auth/signin/init → 200 OK
DEBUG request: POST /appleauth/auth/signin/complete → 401 Unauthorized

So it seems the login is rejected outright, rather than failing during 2FA or session handling.

For context:

• My Apple ID works fine via browser and iPhone
• I already reset the password via iForgot
• The account was previously locked (-20209) due to repeated automated login attempts
• I waited more than 2 weeks before trying again
• I also removed ~/.icloudpd to clear old sessions

That’s why I suspect this might be an Apple-side restriction on API-based logins after the previous account lock, rather than a 2FA issue.

I hope this helps and you have other suggestions?

[rhoopr]

The most likely culprit is the short username format. SRP authentication includes a hash of the username in the cryptographic proof (M1 = H(H(N) XOR H(g) | H(username) | salt | A | B | K)). The client computes this with whatever you pass as --username, and the server computes it with the canonical form it has on record.

/signin/init succeeding just means Apple found your account, it's a loose lookup. But /signin/complete failing with 401 means the proof didn't match, and the username hash is one of the inputs to that proof.

Try using your full Apple ID email address (e.g., username@icloud.com or whatever your actual Apple ID is). Even though the short form worked before, Apple may have changed their normalization behavior, or the password reset may have updated the canonical username form on their end.

If the full email still fails:

• If the password has special characters (!, $, ', etc.), make sure your shell isn't eating them — wrap it in single quotes if prompted, or paste it in
• Your theory about an Apple-side restriction after the -20209 lock is plausible but harder to verify. The username format is the easiest thing to rule out first.

[wip58]

Hi @DriessenbeeR,
I am not a developer, just a slightly more skilled user... Your case is indeed different. I was strugling with my instance until I made a fresh LXC and repeated vanilla setup. Maybe this will work for you, as it did for me.
Wish you luck!

[boredazfcuk]

My other half used to get her account locked all the time. I reckon she must have had credentials leaked from another site, so people were attempting to gain access with an incorrect password.

I must have had to unlock her account 50+ times. Sometimes more than once per day. I ended up changing the email address her account was registered to, and that stopped her getting locked out.

Whenever I unlocked the account, icloudpd would work immediately.

[DriessenbeeR]

Hi @rhoopr and hi @wip58
Thanks a lot for your replies. I could solve my immediate issue.
I had icloudpd running in a VENV environment. I tested it now in a docker environment. And guess what: now it is running like it should again.

I suppose, VENV was not the ideal environment for icloudpd? I suppose I keep it in a Docker environment?

[boredazfcuk]

VENV is always preferred.

Debian even stops you from installing stuff without a VENV nowadays. The parameter to override the behaviour is --break-system-packages

The container I publish uses a VENV inside an Alpine Docker container.

[DriessenbeeR]

Hi @boredazfcuk,

Thanks for your answer!
I just want to clarify my situation.

I first used icloudpd inside a Python virtual environment (VENV), because that is what I initially learned as the recommended way for Python tools.

However, I ran into the problem described above in my setup. Based on the suggestion from @wip58, I tried Docker. After switching to Docker, the issues disappeared, so it seems the problem was related to the environment rather than my script.

At the moment everything is working fine with Docker, so I will probably stick with this setup for stability.
Just out of curiosity: is there any known reason why a VENV setup could behave differently in long-running sync scenarios like this?