I wasn't even aware that was possible. I will IMMEDIATELY do this.
The mere fact this is necessary to stop their data-fiending is disgusting.
You prepend it everytime you run Claude or do you slap that into an .env file?
I would strongly encourage you to create a global shared bashrc for your various devices - my dotfiles repo has tremendously improved my life as an eng who needs to discard dev boxes occasionally (virtual dev boxes)
More generically-named env vars should not be set as an "export" in a rc file like that (IS_DEMO/DISABLE_AUTOUPDATER etc). They'll get exported to every process spawned by the shell, which could have unintended consequences.
You could instead eg:
alias code='DISABLE_AUTOUPDATER=1 IS_DEMO=1 /usr/local/bin/code'
or write a wrapper shell script (analyse/adjust $PATH if you're going to name it the same as an existing binary/script), eg
Every time you run it, it uploads most of your project's code to Anthropic's server. That's just how this category of product works. If you're disgusted by a survey...
This is also related to GH bug [1] and HN post [2]
In that I pointed out that they are sending data back that shouldn't be and is not in compliance with their stated data usage policy [3]. Specifically, message ids which have no purpose other than to link surveys to chat history and this was being sent even when disabled (at the time. I haven't dug into the code since).
Heads up that in most cases I bet this'll result in worse performance as you're then but getting the benefit of the Anthropic tuned system prompts that they use in Claude code, which makes for materially different performance of the agent.
Hi, this is Dickson from the Claude Code team. If you've declined the feedback prompt, it shouldn't keep asking. I'm investigating why the decline state isn't persisting properly from Claude Code.
Claude Code is a very serious tool - in my opinion the only one of its kind suitable as a daily driver.
Without it my startup would grind to a halt. It’s akin to a delivery business needing its fleet of delivery vans.
Every time Claude Code changes we get nervous. Will the few humans who steward this product keep us in mind? Will we be forced to invent our own workflow?
All we want is for our reliable delivery van to keep delivering.
Appreciate you for reading and keeping us in mind as you evolve the product.
I have all these set:
You can add these to your `~/.claude/settings.json`:
Ha! Great minds think alike! I posted the same thing 3 seconds slower =(
Just an FYI to several of the posters here.
You CAN set these as env vars in your shell, but I prefer to stick 'em in the Claude settings.json:
This keeps your main environment from getting cluttered.what does the last one do?
"Added IS_DEMO environment variable to hide email and organization from the UI, useful for streaming or recording sessions"
from the changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELO...
Hmmm, they already added this which has same functionality: CLAUDE_CODE_HIDE_ACCOUNT_INFO
I wasn't even aware that was possible. I will IMMEDIATELY do this. The mere fact this is necessary to stop their data-fiending is disgusting. You prepend it everytime you run Claude or do you slap that into an .env file?
These are good to append to your .bashrc or .zshrc (depending on your shell of choice) and they'll be picked up.
Oh, shame, I use claude across 4-5 devices, but thanks anyways.
I would strongly encourage you to create a global shared bashrc for your various devices - my dotfiles repo has tremendously improved my life as an eng who needs to discard dev boxes occasionally (virtual dev boxes)
Arent you going to be banned by using it on too many devices ?
They charge based on consumption as the comment below me stated.
Ah sorry, I was thinking about the Pro / Max plan, not API token usage
The Pro and Max plans don't have a device limit either.
I frequently use Claude code in disposable virtual machines.
I think they charge based on consumption, not devices.
More generically-named env vars should not be set as an "export" in a rc file like that (IS_DEMO/DISABLE_AUTOUPDATER etc). They'll get exported to every process spawned by the shell, which could have unintended consequences.
You could instead eg:
or write a wrapper shell script (analyse/adjust $PATH if you're going to name it the same as an existing binary/script), egYou can also put these into settings.json.
https://code.claude.com/docs/en/settings
And, if you really hate manuals, you can just ask Claude to write the settings for you =D
> to stop their data-fiending
Every time you run it, it uploads most of your project's code to Anthropic's server. That's just how this category of product works. If you're disgusted by a survey...
Tangentially related, I had created this issue which has plenty of support - people feel very strongly about it for various reasons.
https://github.com/anthropics/claude-code/issues/4034
It's really a trivial fix so I'm disappointed not to have received any input from the Anthropic folks all this time.
This is also related to GH bug [1] and HN post [2]
In that I pointed out that they are sending data back that shouldn't be and is not in compliance with their stated data usage policy [3]. Specifically, message ids which have no purpose other than to link surveys to chat history and this was being sent even when disabled (at the time. I haven't dug into the code since).
[1] https://github.com/anthropics/claude-code/issues/8036 [2] https://news.ycombinator.com/item?id=45838297 [3] https://code.claude.com/docs/en/data-usage
https://opencode.ai/ supports Claude (and basically all other models) and it's opensource. You don't have to use CC.
Heads up that in most cases I bet this'll result in worse performance as you're then but getting the benefit of the Anthropic tuned system prompts that they use in Claude code, which makes for materially different performance of the agent.
Hi, this is Dickson from the Claude Code team. If you've declined the feedback prompt, it shouldn't keep asking. I'm investigating why the decline state isn't persisting properly from Claude Code.
I would appreciate it if you could create an issue for this at https://github.com/anthropics/claude-code/issues so we can continue troubleshooting there.
Hi Dickson,
Thanks for talking to this community.
Claude Code is a very serious tool - in my opinion the only one of its kind suitable as a daily driver.
Without it my startup would grind to a halt. It’s akin to a delivery business needing its fleet of delivery vans.
Every time Claude Code changes we get nervous. Will the few humans who steward this product keep us in mind? Will we be forced to invent our own workflow?
All we want is for our reliable delivery van to keep delivering.
Appreciate you for reading and keeping us in mind as you evolve the product.
Hi Dickson,
while you're here, would you generously allocate a couple minutes to assess this other issue? https://github.com/anthropics/claude-code/issues/4034
It's low-hanging fruit.
What is this post? Is HN the Claude support channel? They have a bug tracker. Use it.
What are you asking? Or is this just a rant?
Goodness gracious
Imagine you bought a van for your business and one day you unlock it to find the interior has been repainted with rainbows.
This is really annoying!
The van still works though, so on you go.
Later that day, you look into who else sells similar vans, and find out all the other van makers will only sell you a chassis, byo wheels.
Switch to Codex