[BUG] `claude` on Mac deletes the `.credentials.json` file that `claude` on Linux uses
Status Fixed / completed
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 9 comments · opened May 29, 2025 · closed Jun 17, 2025
Environment
- Platform (select one):
- [x] Anthropic API
- [ ] AWS Bedrock
- [ ] Google Vertex AI
- [ ] Other: <!-- specify -->
- Claude CLI version: <!-- output of
claude --version--> 1.0.5 - Operating System: <!-- e.g. macOS 14.3, Windows 11, Ubuntu 22.04 --> macOS + ubuntu image
- Terminal: <!-- e.g. iTerm2, Terminal App --> alacritty
Bug Description
I run claude both on Mac natively and using containers. when I use a container, I map in .claude as a volume to share settings. linux writes its creds to .claude/.credentials.json; mac doesn't use them.
I was finding that I'd need to log into claude code when again fairly often when using containers, and that the creds file was disappearing. I added a probe and it shows that it's the Mac claude process deleting the file — below we can see unlink from a node process.
is that intended? does it expire?! assuming it doesn't expire, ideally claude wouldn't delete files just because it doesn't need them.
sudo fs_usage -w -f filesystem \
| grep -iE '\.claude/\.credentials\.json'
Password:
09:44:10.978130 access (___F) /Users/maximilian/.claude/.credentials.json 0.000006 node.36584176
09:44:10.978389 unlink /Users/maximilian/.claude/.credentials.json 0.000235 node.36584176
09:44:11.114233 lstat64 [ 2] /System/Volumes/Data/Users/maximilian/.claude/.credentials.json 0.000014 fseventsd.450762
9 Comments
Thanks for the report! This is intended behavior (cleaning up plain text credentials when successfully storing them in macos keychain), but would be curious to hear about your workflow. Would running inside the container with a different
CLAUDE_CONFIG_DIRpath work for you?ok — though that means it's not possible to run in a container without logging in on each switch to & back
I can mount a different path —
~/.claude-linux:~/.claudeand have a task which copies over myCLAUDE.mdto~/.claude-linux/at some frequency I guess? doesn't seem idealor if
claudeis going to clean up things it doesn't use from other OSs, should it put them in OS-specific paths, such as~/.claude/linux/.credentials.json...You can use CLAUDE.md imports instead of copying over (i.e. have container dir's CLAUDE.md import your main one)!
but the current state of
claudeprevents mounting~/.claudeinto the container! so~/.claude/CLAUDE.mdisn't then available in the containerdoes that make sense?
(unless it's a proposal to have two mounts to differently named locations and then map one back into the other with an import that's invalid on the host)
you could create a CLAUDE.md file inside your container mounted dir and then @- import it from
~/.claude/CLAUDE.mdto avoid needing two mountsThis sounds like a lot of workarounds for what I'm guessing would actually be a really simple fix in claude code :(. Just give us a config parameter to set so
~/claude/.credentials.jsonisn't deleted or give us aCLAUDE_CREDENTIALS_FILEenv var that we can use in container configs so that we can use~/.claude/.container-credentials.jsonas the credentials file.As for use case, I do almost all of my dev work in devcontainers. This is an example config of how I've got things setup to use claude code. Copy this json to
${mydir}/.devcontainer/devcontainer.json, load${mydir}in vscode, and then have vscode load up the devcontainer.I know devcontainer users are in the minority, but considering you guys maintain a devcontainer feature (https://github.com/anthropics/devcontainer-features/tree/main), it would be really nice if we didn't have to re-login due to the credentials getting deleted on the host machine.
any news?
@levpopov this should be reopened. Using containers to isolate Claude code instances is becoming more popular. The current behaviour is problematic for people using these flows. Either fix this, or, ideally, provide a way for M2M authentication so we don't need to rely on that file.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.