Everything else including email and username should be changeable (provided there's no conflict with other accounts)
I appealed and got a standard Google Forms response. There was no follow-up after that. It never got fixed and I never tried again... plenty of free, more accessible fish out there, and various agents like Copilot give me access to Sonnet anyway.
But now I wonder, what is it about the account that triggered this block. If it was because of the reputation of the account, how did Anthropic even know that this account was created a few weeks ago?
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
The email I signed up for got compromised a couple of months ago and I ended up having to delete my entire GPT account, losing all my history, to recreate using a new email.
It was super annoying and, out of hundreds of websites I had to update, only OpenAI and Anthropic wouldn't let me change my email. A few of them required contacting support with some sort of proof, but at least doable.
Historically, outlook emails have been very easy for this compared to gmail addresses, which require phone numbers, etc.
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.'
I made the mistake of using my company provided ChatGPT account for non-work stuff. It was fine before the memory features came out. But now I'm regretting not having a separate personal one.
Edit: For ChatGPT (not sure about Claude) https://help.openai.com/en/articles/9106926-transferring-con...
Perplexingly, this business account is as bad as a Google Workplace account. It has restrictions on it that I didn't have when I was on my own account. As an example, I can't share chats outside the organization. Fine, all right then.
> 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]
The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her.
Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement.
https://gdpr-info.eu/art-16-gdpr/
Obviously if you change your email address, the old one ceases to be correct, even if it was correct before.
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.
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.
It's king of weird, but I have tried over the years to develop a do-just-what-is-necessary-now mindset in my software engineering work, and I just can't make my mind work that.
For me, doing things right is a way for me to avoid having to hold too much context in my head while working on my projects. I know the idiomatic way to do something, and if i just do it that way, then when I come back to it I know it should and is architectured.
Couldn't you use this to figure out which emails have registered with Claude?
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.