Anecdote, but I've never been able to use Claude (directly) because their defense systems seem overly sensitive to your email address. I signed up for Claude using a relatively new Outlook email address that I set up for an independent purpose. My account got instabanned. Like, I couldn't proceed at all. I don't even know what the Claude UI looks like. All I could do was appeal using a Google Form.
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?
There are vendors like Emailage that somehow determine the age of email addresses. Very useful because fraudsters tend to buy credit cards and bank accounts, then need to complete the identity by registering an email address for that identity.
Historically, outlook emails have been very easy for this compared to gmail addresses, which require phone numbers, etc.
One of the reasons "aged" account marketplaces got more popular. People buy from vendors that farm a ton of these accounts and wait to sell them, or those reselling compromised accounts (especially with EDU accounts before institutions actually implemented security controls).
Same here - though I used my personal email domain with claude as the local/username. They autobanned that one and then banned my actual personal email. The only one that worked was a Google login. My appeal had a boilerplate response.
Another anecdote, but I signed up for Claude using a brand spanking new iCloud private relay address that was created specifically for Claude and it let me in without any problems. We're talking 10 seconds or less from address creation to account creation.
It's worth checking the spam score if its a new domain and see if there's anything on the internet archive. I learned this the hard way and now I check before buying
How new was your email address? When I set up my work Claude account with my near fresh email (I had just set up Outlook to work with my domain) I had no issues.
Maybe they should read that article (that was on HN) from the other day and switch to using account numbers with no customer information since that'd be about the same difference anyway given this behavior.
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
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.
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.
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.
> Attacker must compromise the original inbox permanently, which is much harder
This may need further analysis. I'd guess that a significant fraction of the people that want to change the email address that identifies them to a service want to do so because they have a new email address that they are switching to.
Many of those will be people who lose access to the old email address after switching. For example people who were using an email address at their ISP's domain who are switching ISPs, or people who use paid email hosting without a custom domain and are switching to a different email provider.
A new customer of that old provider might then be able to get that old address. You'd think providers would obviously never allow addresses used by former customers to be reused, but nope, some do. Even some that you'd expect to not do so, such as mailbox.org [1] and fastmail.com, allow addresses to be recycled.
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.
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.
What logical fallacy, exactly? I think you're perhaps misunderstanding the conversation. This translates just fine to your proposed analogy.
In your analogy, the claim would be that some online account is tied to a laptop and whoever possesses the laptop has access to that account. The online service does not permit the account owner to revoke access from that laptop and move the account to a different laptop. I stand by my statement that this would be a serious security hazard. Because yes, laptops can and do get hacked or stolen, just like email addresses.
Where your analogy isn't quite as strong is that at least you can generally add additional anti-theft protections such as full-disk encryption to a laptop, while with an email account generally 2FA is the best you can do.
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?
>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.'
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.
It sort of makes sense. These guys were AI labs before they were ever web developers. They prompted me to switch to a business account, so I did but my business email is not my personal email and I promptly lost all the old chats. Well, all right then.
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.
You can't change ChatGPT email address, either, fwiw.
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.
Is there a way to export out of one account into another?
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.
I wonder how they'd handle this under the GDPR, which has an explicit "Right to rectification".
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.
I don't know. I actually find it harder and more stressful to write code in a way that does not meet a certain quality level. it require me to actually think more.
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.
Anecdote, but I've never been able to use Claude (directly) because their defense systems seem overly sensitive to your email address. I signed up for Claude using a relatively new Outlook email address that I set up for an independent purpose. My account got instabanned. Like, I couldn't proceed at all. I don't even know what the Claude UI looks like. All I could do was appeal using a Google Form.
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?
There are vendors like Emailage that somehow determine the age of email addresses. Very useful because fraudsters tend to buy credit cards and bank accounts, then need to complete the identity by registering an email address for that identity.
Historically, outlook emails have been very easy for this compared to gmail addresses, which require phone numbers, etc.
One of the reasons "aged" account marketplaces got more popular. People buy from vendors that farm a ton of these accounts and wait to sell them, or those reselling compromised accounts (especially with EDU accounts before institutions actually implemented security controls).
Same here - though I used my personal email domain with claude as the local/username. They autobanned that one and then banned my actual personal email. The only one that worked was a Google login. My appeal had a boilerplate response.
Another anecdote, but I signed up for Claude using a brand spanking new iCloud private relay address that was created specifically for Claude and it let me in without any problems. We're talking 10 seconds or less from address creation to account creation.
It's worth checking the spam score if its a new domain and see if there's anything on the internet archive. I learned this the hard way and now I check before buying
How new was your email address? When I set up my work Claude account with my near fresh email (I had just set up Outlook to work with my domain) I had no issues.
IIRC it was about 3 weeks old. I hadn't used it for anything else in that time either, which probably also contributd to the lack of reputation.
I have never been able to use it because they require a phone number during registration and would always reject mine.
I don't think this is a requirement anymore
The authentication account should have a permanent stable identifier that should be the provider's responsibility to issue and manage.
Everything else including email and username should be changeable (provided there's no conflict with other accounts)
> (provided there's no conflict with other accounts)
Couldn't you use this to figure out which emails have registered with Claude?
You can do this on almost every online service by trying to create an account with an email that already has an account.
It's the same with openai.
I had to switch emails so I had to create a new account.
Seems bonkers.
Maybe they should read that article (that was on HN) from the other day and switch to using account numbers with no customer information since that'd be about the same difference anyway given this behavior.
OpenAI doesn't let you change your email address, either.
Been really stuck with the email I entered earlier with ChatGPT. Hope they change this policy soon
Why is this the case? I don't understand, can somebody explain the logic to me here?
Maybe used the email address as a primary key. Ask me how I know.
That was my first guess TBH. Mostly because it seems like the kind of thing scientists writing Python would do.
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
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]
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.
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.
I fail to see how preventing email changes solves the issues you listed, or how allowing it necessarily makes them worse.
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.
> Attacker must compromise the original inbox permanently, which is much harder
This may need further analysis. I'd guess that a significant fraction of the people that want to change the email address that identifies them to a service want to do so because they have a new email address that they are switching to.
Many of those will be people who lose access to the old email address after switching. For example people who were using an email address at their ISP's domain who are switching ISPs, or people who use paid email hosting without a custom domain and are switching to a different email provider.
A new customer of that old provider might then be able to get that old address. You'd think providers would obviously never allow addresses used by former customers to be reused, but nope, some do. Even some that you'd expect to not do so, such as mailbox.org [1] and fastmail.com, allow addresses to be recycled.
[1] https://kb.mailbox.org/en/private/e-mail/when-is-a-deleted-a...
[2] https://www.change.org/p/stop-fastmail-recycling-email-addre...
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.
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.
This is a logical fallacy. That's like saying security of the website is not important because someone can still steal your laptop.
What logical fallacy, exactly? I think you're perhaps misunderstanding the conversation. This translates just fine to your proposed analogy.
In your analogy, the claim would be that some online account is tied to a laptop and whoever possesses the laptop has access to that account. The online service does not permit the account owner to revoke access from that laptop and move the account to a different laptop. I stand by my statement that this would be a serious security hazard. Because yes, laptops can and do get hacked or stolen, just like email addresses.
Where your analogy isn't quite as strong is that at least you can generally add additional anti-theft protections such as full-disk encryption to a laptop, while with an email account generally 2FA is the best you can do.
They also allow google accounts. I guess they use the email for that too?
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?
>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.'
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.
To reduce subscription sharing. It’s not complicated.
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.
It sort of makes sense. These guys were AI labs before they were ever web developers. They prompted me to switch to a business account, so I did but my business email is not my personal email and I promptly lost all the old chats. Well, all right then.
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.
You can't change ChatGPT email address, either, fwiw.
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.
Is there a way to export out of one account into another?
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...
You can export your data to an email address but there's no import/transfer functionality that I'm aware of
You can clear & turn off the memory stuff no?
They should vibe code a fix
Clearly we need an EmailChange-Verified benchmark since this is such a difficult problem.
I wanted to switch so I could use single sign on with my google account because they use the magic link login but I couldn’t. So sad :(
I wonder how they'd handle this under the GDPR, which has an explicit "Right to rectification".
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.
They don't. They haven't been fined yet to care.
The technology just isn't there yet.
They should dogfood their own product and ask Claude to fix it for them. :|
Same like openAI
Maybe they can use an LLM to help them implement this feature ? Oh wait a second...
(wrong thread)
You're probably in the wrong thread. This is about changing email addresses for accounts. That's not a payment-gated feature on Google.
Guys remember this kind of stuff when you are building side projects. You can just ship you don’t need every feature on day one.
the ability to change email address is not that complicated of a feature to postpone to later.
maybe they should ask CC to fix this...
It’s not a complicated feature and it’s also not required on day 1. At Cronitor we did not have it for nearly 2 years.
I don't know. I actually find it harder and more stressful to write code in a way that does not meet a certain quality level. it require me to actually think more.
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.
future of humanity btw.
its ridiculous
Do they use Okta or some other 3rd party Auth solution?
Vibe code this…lol
Oh, the wonders provided to humanity by "AI"!
Can this be used as a dagger to the heart of all the arguments about the revolutionary nature of what we currently call AI?
What a mockery this is.