"Update: Root cause found — this was a bug in a tool I built that was running locally for testing, not Claude Code.
When the tool's configuration pointed at a local working directory, it would hard-reset that directory every poll cycle to reflect the remote — destroying all uncommitted changes to tracked files, exactly as described in the issue."
So much "thorough investigation" done but the author did not consider turning off claude for 10 minutes to see if the problems stops? lol
Flagged the submission as it's inaccurate. Will unflag if title gets changed to something like "dev builds script that resets their git repo every 10 minutes, forgets about it, blames claude code with no evidence"
Let's focus on the real issue here, which is that HN has apparently normalized the double hyphen in the title to an en dash--yes, an en dash, not even an em dash.
I agree that it should be left as a double hyphen, but an en dash is far more appropriate considering the decades-long precedent set by LaTeX (and continued by Typst).
> Process monitoring at 0.1-second intervals found zero git processes around reset times.
I don’t think this is a valid way of checking for spawned processes. Git commands are fast. 0.1-second intervals are not enough. I would replace the git on the $PATH by a wrapper that logs all operations and then execs the real git.
I think this post potentially mischaracterises what may be a one off issue for a certain person as if it were a broader problem. I'm guessing some context has been corrupted?
Not sure I understand, wouldn't permissions prevent this? The user runs with --dangerously-skip-permissions so they can expect wild behaviour. They should run with permissions and a ruleset.
Who would have guessed that running a binary blob dev tool, that is tied to a SaaS product, which was mostly vibe-coded, could lead to mysterious, hard to debug problems?
I have a similar issue, where normally I use claude-code in an srt or bwrap direct sandbox, but when I don't, claude-code will call gh _every_ time I backspace out of a /command or escape a menu such a /mcp, any time I paste something, as well as on some timer that sounds like the issue owner's complaint of 10 minutes.
I know because I use keepassxc as my secret provider, so I get an approval prompt to allow or deny it _every_time_, so I darn well notice it as it'll grab focus when typing something. Inside a sandbox it tries but without access to creds or env, it just silently fails, so I never noticed while in-sandbox, just when out-of-sandbox, which I do occasionally to let it do some sysadmin/housecleaning task for me.
I finally asked Claude why:
"Root cause: It's Claude Code's built-in git context feature, not hooks.
So unless you keep your secrets open to the user regardless who's asking for them, it'll nag you to escape out of menus with a gh query. KeepassXC doesn't let you set a per-session limit, it's either right now for forever.
I give you my personal experinces. I use it for everything design, coding, testing, deploying to kubernetes cluster, fixing issues on cluster. I use it to fix not only dev env issues, I use it for production issues. Confidently. Have things gone wrong. Sure. But mistakes have been rare (and catastrophic mistake - non recoverable , even rarer).
Everytime a mistake has happened,on diggin in I was always trace it back to something which I did wrong - either being careless in reading what it told me , or careless in telling what I want. I have had git code corruption issues, it overwrote uncommited working code with non working code. But it was my mistake to not tell it to commit the code before makign changes. It deleted QA cluster database but becuase I told it to delete it thinking it was my dev setup db. Net net. It;s mistakes are more a reflection of me as its supervisor than anything else.
191 comments
"Update: Root cause found — this was a bug in a tool I built that was running locally for testing, not Claude Code.
When the tool's configuration pointed at a local working directory, it would hard-reset that directory every poll cycle to reflect the remote — destroying all uncommitted changes to tracked files, exactly as described in the issue."
Flagged the submission as it's inaccurate. Will unflag if title gets changed to something like "dev builds script that resets their git repo every 10 minutes, forgets about it, blames claude code with no evidence"
(Or... do they?? Hmm, ok, maybe I need to let this roll around in my mind.)
comments: "ThE tItLe iS aI cOded !!!1"
triple hyphens —
git reset --hard origin/mainMost likely, the developer ran
/loop 10mor asked claude to create a cron task that runs every 10 minutes and refreshes & resets git.> Process monitoring at 0.1-second intervals found zero git processes around reset times.
I don’t think this is a valid way of checking for spawned processes. Git commands are fast. 0.1-second intervals are not enough. I would replace the git on the $PATH by a wrapper that logs all operations and then execs the real git.
--dangerously-skip-permissionsso they can expect wild behaviour. They should run with permissions and a ruleset.> Update: Root cause found — this was a bug in a tool I built that was running locally for testing, not Claude Code.
And if you force push to one of your own machines you can use the reflog[2].
[0]: https://stackoverflow.com/a/78872853 [1]: https://stackoverflow.com/a/48110879 [2]: https://stackoverflow.com/a/24236065
I know because I use keepassxc as my secret provider, so I get an approval prompt to allow or deny it _every_time_, so I darn well notice it as it'll grab focus when typing something. Inside a sandbox it tries but without access to creds or env, it just silently fails, so I never noticed while in-sandbox, just when out-of-sandbox, which I do occasionally to let it do some sysadmin/housecleaning task for me.
I finally asked Claude why: "Root cause: It's Claude Code's built-in git context feature, not hooks.
So unless you keep your secrets open to the user regardless who's asking for them, it'll nag you to escape out of menus with a gh query. KeepassXC doesn't let you set a per-session limit, it's either right now for forever.
Everytime a mistake has happened,on diggin in I was always trace it back to something which I did wrong - either being careless in reading what it told me , or careless in telling what I want. I have had git code corruption issues, it overwrote uncommited working code with non working code. But it was my mistake to not tell it to commit the code before makign changes. It deleted QA cluster database but becuase I told it to delete it thinking it was my dev setup db. Net net. It;s mistakes are more a reflection of me as its supervisor than anything else.