alt Hacker NewsClaude Code runs Git reset –hard origin/main against project repo every 10 mins
Comments
I spent some time investigating this, and the issue is not accurate - Claude Code itself does not have code that spawns `git reset --hard origin/main`
Most likely, the developer ran `/loop 10m <prompt>` or 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.
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?
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?
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.
This looks similar to a bug report Claude Code offered to file for me after it became confused about my shell environment. The author is probably running something (maybe /loop as suggested in the comment.) In my case, a restart fixed the envs.
As a side note. Always configure remote to reject any kind of trunk push. And ideally any forced push on branches.
As an FYI you can recover from force pushes to GitHub using their UI[0] or their API[1].
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
Regardless of if this is common its getting popular because its objectively hilarious and we can all see it being possible.
This is exactly why guardrails need to be deterministic and outside the model.
I'm curious how common this is or if this just affects this one user.
It’s a feature not a bug!
95+ entries that are logged at 10 min intervals
/10 * * * /usr/ schedules script execution
Has anyone been able to replicate the behavior described in this issue yet?
Highly recommend to deny commands in user settings.json like git reset
Have you considered that Claude set up a crontab that does that programmatically? Every 10 mins seems awfully, idk, regular.
The obvious solution is to just copy paste it into Claude itself and ask it to fix. Works for almost any Claude problem
if an idea can't be vibecoded in under 10 minutes, it's not worth pursuing. Checks out
that must be a very powerful claude.md
is this token friendly?
Probably does it to reduce context for regex/git history searches
obviously a user mistake, not a claude code bug
But it doesn't.
While that's obviously a bug which should be fixed, having stuff just sitting around uncommitted for days (which is much longer than 10 mins) is an anti-pattern (that I used to fall into).
tbf, that's claude's workspace
do not share a workspace with the llm, or with anybody for that matter.
How would the llm even distinguish what was wrote by them and what was written by you ?
I’m having this weird vision of a “the matrix 3” type machine crawling around inside Microsoft’s GitHub servers central repository and just wreaking havoc.
This whole LLM thing is a blast, huh?
cool. if you choose to use a non-deterministic black box of bullshit, should you really be surprised when it shits all over your floor?
[dead]
[dead]
[dead]
[dead]
[dead]
Hope they don’t auto-close this one in two weeks
Truly is a brave new world we're in
-
I guess some people are upset at my brave new world characterization, but even as someone deriving value from Claude Code we've jumped the shark on AI in development.
The idea a natural request can get Claude to invoke potentially destructive actions on a timer is silly
https://code.claude.com/docs/en/scheduled-tasks#set-a-one-ti...
What would it cost if the /loop command was required instead of optional?
Isn't this a natural consequence of how these systems work?
The model is probabilistic and sequences like `git reset --hard` are very common in training data, so they have some probability to appear in outputs.
Whether such a command is appropriate depends on context that is not fully observable to the system, like whether a repository or changes are disposable or not. Because of that, the system cannot rely purely on fixed rules and has to figure intent from incomplete information, which is also probabilistic.
With so many layers of probabilities, it seems expected that sometimes commands like this will be produced even if they are not appropriate in that specific situation.
Even a 0.01% failure rate due to context corruption, misinterpretation of intent, or guardrail errors would show up regularly at scale, that is like 1 in 10000 queries.
That's interesting man, that's pretty f***' interesting. I don't think I've seen it though. I've let it run for hours making changes overnight and I only do git operations manually.
Oh, but maybe allowing it to do remote git operations is a necessary trigger.
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.