[BUG] `/memory` command creates a new CLAUDE.md file *and* also writes to `.gitignore` to ignore that file *without permission*
Environment
- Platform (select one):
- [ ] Anthropic API
- [ ] AWS Bedrock
- [ ] Google Vertex AI
- [X] Other: <!-- specify --> Claude Code from VS-Code, also reproduced in Terminal (zsh).
- Claude CLI version: <!-- output of
claude --version--> 0.2.55 - Operating System: <!-- e.g. macOS 14.3, Windows 11, Ubuntu 22.04 --> 15.3.2
- Terminal: <!-- e.g. iTerm2, Terminal App --> VS-Code Terminal, also reproduced in zsh.
Bug Description
<!-- A clear and concise description of the bug -->
I invoked the /memory slash-command, which opens a menu to select which CLAUDE file you want to edit (project, project local, or user/system). I selected an option which didn't exist yet, so Claude created it. It also wrote to my .gitignore to ignore the file. I guess the instructions kind of tell you that it's going to create a git-ignored file, but I did not expect this behavior. I think it would be clearer if you stated that the .gitignore file will be automatically updated/written-to without approval - this was totally confusing to me.
I just created a blank directory and started Claude. I immediately ran /memory and these are the options:
Project memory Checked in at ./CLAUDE.md │
│ Project memory (local) Gitignored in ./CLAUDE.local.md │
│ User memory Saved in ~/.claude/CLAUDE.md The directory is not even a git repo (not git-initialized yet). So these options are definitely confusing/wrong.
Steps to Reproduce
- <!-- First step -->
- <!-- Second step -->
- <!-- And so on... -->
Expected Behavior
<!-- What you expected to happen -->
Actual Behavior
<!-- What actually happened -->
Additional Context
<!-- Add any other context about the problem here, such as screenshots, logs, etc. -->
7 Comments
If nothing else I think it's fair to say we shouldn't create
.gitignoreif the project isn't a git repoSorry, just to be clear, it didn't create a new
.gitignore, but it wasn't clear to me that it was going to edit the existing.gitignorewithout asking permission to write.EDIT: The language of "Checked in at..." and "gitignore at..." falsely implies there already is a git repo, e.g.
That makes sense! The intention of the .local.md is that it isn't checked in, but maybe we should communicate that better or prompt the user.
Thanks for the report @hesreallyhim ! We'll update this to be less confusing.
Out of curiosity, why did you choose the
Project memory (local)option? What did you expect this selection to do?@levpopov i guess i don't really know, i probably just wanted try it. It occurred to me later that the reasoning is that CLAUDE.md is for project/team-wide info/preferences, while CLAUDE.local.md is for personal/user info, which is why it would make sense to gitignore it. I glanced at the docs and I can see now that this is indeed documented. So I think this is a pretty minor complaint, I would just say that it might be nice to have an approval step before editing the
.gitignorefile since that specific part of it is not (clearly?) documented, so it sort of goes against the "rules" for someone who prefers that Claude doesn't write anything without explicit approval. E.g. if I'm working on a shared project, the.gitignoreis probably going to be committed, and maybe that in itself is a decision I would like to have (explicit) control over. Like if I create a.claude/folder, e.g., it isn't automatically gitignored, so automatically writing to.gitignoremight seem a little too opinionated. But, in any case, I would not consider this a "BUG" since it is documented, and maintainers/owners can feel free to close this whenever they want, esp. in light of your last response. Thanks!I guess maybe it's worth noting that Claude did hallucinate when I asked it how the
.gitignorefile got changed, and managed to talk itself into saying that it was because of the/initcommand. This is all in the actual bug report, but FWIW.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.