Anthropic: You can't change your Claude account email address

Why is this the case? I don't understand, can somebody explain the logic to me here?

I can only assume there is some database structuring issue where things would potentially be broken if emails aren't update correctly, but I'm just guessing.

Maybe used the email address as a primary key. Ask me how I know.

I know, what’s so special about email? The common thing between your accounts, that the company that has a lot of chat history is allowing you not to change?

Well it does eliminate a whole list of problems related to account takeover, account recovery workflows, legal questions regarding which email owns the data, etc. Sometimes less is more. Secure, reliable, simple.

So with all their billions they could not get a proper software engineer to architect their project?

Unless there is some deep technical reason why things have to be this way, which I very much doubt.

And now they can't change it? Where is Claude when you need him/her

I fail to see how preventing email changes solves the issues you listed, or how allowing it necessarily makes them worse.

They also allow google accounts. I guess they use the email for that too?

That was my first guess TBH. Mostly because it seems like the kind of thing scientists writing Python would do.

>When creating an account, please make sure you use an email you'll have long-term access to.

I'm just guessing, but the above might suggest a potential incentive: They would like you to hand over a valuable/longterm email, as opposed to a temporary email (for supposedly more privacy or testing), by making it difficult to change it later.

'Dark patterns are the pavement of todays corporate infrastructure.'

To reduce subscription sharing. It’s not complicated.

The funny thing is that if you ask Claude if you should use email address as a primary key it will pretty adamantly warn you away from it:

> I'd recommend against using email as the primary key for a large LLM chat website. Here's why:

> Problems with email as primary key:

> 1. Emails change - Users often want to update their email addresses. With email as PK, you'd need to cascade updates across all related tables (chat sessions, messages, settings, etc.), which is expensive and error-prone

> [Edited for length]

If anything, this makes account takeover and account recovery way more difficult. It probably makes a bunch of legal stuff easier for them, but that’s about it.

If I had to guess, it's to stop people from acquiring a high reputation with Anthropic and then selling the account or giving it to other people.

Obviously, there's a way to do that still. Not saying it's a good idea. But if I had to guess as to why, that's the one that comes to mind.

That's pretty obvious to anyone who had to maintain a high traffic site. Just the tip of the iceberg (I haven't included additional legal issues and other):

1.1 Strong protection against account takeover

Email change is one of the most abused recovery vectors in account takeover (ATO).

Eliminating email changes removes:

Social-engineering attacks on support

SIM-swap → email-change chains

Phished session → email swap → lockout of real user

Attacker must compromise the original inbox permanently, which is much harder.

1.2 No “high-risk” flows

Email change flows are among the highest-risk product flows:

Dual confirmation emails

Cooldown periods

Rollback windows

Manual reviews

Fixed email removes an entire class of security-critical code paths.

1.3 Fewer recovery attack surfaces No need for:

“I lost access to my email” flows

Identity verification uploads

Support-driven ownership disputes

Every recovery mechanism is an attack surface; removing them reduces risk.

You're very wrong, because account takeover can still happen due to a compromised email account. People can and do permanently lose access to their email account to a third party.

This is a logical fallacy. That's like saying security of the website is not important because someone can still steal your laptop.

Having worked in security on a fairly high profile, highly visible, largely used product — one of the fundamental decisions that paid off very well was intentionally including mechanisms to prevent issues with other businesses (like Google) from impacting user abilities for us.

Not having email change functionality would have been a huge usability, security, and customer service nightmare for us.

Regardless of anything else, not enabling users to change their email address effectively binds them to business with a single organization. It also ignores the fact that people can and do change emails for entirely opaque reasons from the banal to the authentically emergent.

ATO attacks are a fig leaf for such concerns, because you, as an organization, always have the power to revert a change to contact information. You just need to establish a process. It takes some consideration and table topping, but it’s not rocket science for a competent team.