I've been trying to stop the coding assistants from making git commits on their own and nothing has been working.

▲ zmmmmm a day ago | parent | next [-]

hah - i'm the opposite, I want everything done by the AI to be a discrete, clear commit so there is no human/AI entanglement. If you want to squash it later that's fine but you should have a record of what the AI did. This is Aider's default mode and it's one reason I keep using it.

	▲	vitaflo 15 hours ago \| parent [-]
		It’s the first thing I turn off in Aider.

▲ Aurornis 11 hours ago | parent | prev | next [-]

Which coding assistant are you using?

I'm a mild user at best, but I've never once seen the various tools I've used try to make a git commit on their own. I'm curious which tool you're using that's doing that.

	▲	jason_oster 4 hours ago \| parent [-]
		Same here. Using Codex with GPT-5.2 and it has not once tried to make any git commits. I've only used it about 100 times over the last few months, though.

▲ algorias a day ago | parent | prev | next [-]

run them in a VM that doesn't have git installed. Sandboxing these things is a good idea anyways.

▲ godelski a day ago | parent | next [-]

  > Sandboxing these things is a good idea anyways.

Honestly, one thing I don't understand is why agents aren't organized with unique user or group permissions. Like if we're going to be lazy and not make a container for them then why the fuck are we not doing basic security things like permission handling.

Like we want to act like these programs are identical to a person on a system but at the same time we're not treating them like we would another person on the system? Give me a fucking claude user and/or group. If I want to remove `git` or `rm` from that user, great! Also makes giving directory access a lot easier. Don't have to just trust that the program isn't going to go fuck with some other directory

▲ inopinatus 21 hours ago | parent | next [-]

The agents are being prompted to vibe-code themselves by a post-Docker generation raised on node and systemd. So of course they emit an ad-hoc, informally-specified, bug-ridden, slow reimplementation of things the OS was already capable of.

▲ apetresc a day ago | parent | prev | next [-]

What's stopping you from `su claude`?

	▲	godelski a day ago \| parent [-]
		I think there's some misunderstanding... What's literally stopping me is `su: user claude does not exist or the user entry does not contain all the required fields` Clearly you're not asking that... But if your question is more "what's stopping you from creating a user named claude, installing claude to that user account, and writing a program so that user godelski can message user claude and watch all of user claude's actions, and all that jazz" then... well... technically nothing. But if that's your question, then I don't understand what you thought my comment said.

▲ immibis 15 hours ago | parent | prev [-]

Probably because Linux doesn't really have a good model for ad-hoc permission restrictions. It has enough bits to make a Docker container out of, but that's a full new system. You can't really restrict a subprocess to only write files under this directory.

▲

newsoftheday 10 hours ago | parent [-]

For plain Linux, chmod, chmod's sticky bit and setfacl provide extensive ad hoc permissions restricting. Your comment is 4 hours old, I'm surprised I'm the first person to help correct its inaccuracy.

	▲	immibis 44 minutes ago \| parent [-]
		How can those be used to restrict a certain subprocess to only write in a certain directory?

▲ zmmmmm a day ago | parent | prev [-]

but then they can't open your browser to administer your account.

What kind of agentic developer are you?

▲ manwds a day ago | parent | prev | next [-]

Why not use something like Amp Code which doesn't do that, people seem to rage at CC or similar tools but Amp Code doesn't go making random commits or dropping databases.

	▲	hdra a day ago \| parent [-]
		just because i havent gotten to try it out really. but what is it about Amp Code that makes it immune from doing that? from what i can tell, its another cli tool-calling client to an LLM? so fwict, i'd expect it to be subject to the indeterministic nature of LLM calling the tool i dont want it to call just like any others, no?

▲ AstroBen a day ago | parent | prev | next [-]

Are you using aider? There's a setting to turn that off

▲ dust-jacket 13 hours ago | parent | prev | next [-]

require commits to be signed.

▲ SoftTalker a day ago | parent | prev [-]

Don't give them a credential/permission that allows it?

▲

godelski a day ago | parent | next [-]

Typically agents are not operating as a distinct user. So they have the same permissions, and thus credentials, as the user operating them.

Don't get me wrong, I find this framework idiotic and personally I find it crazy that it is done this way, but I didn't write Claude Code/Antigravity/Copilot/etc

▲

AlexandrB a day ago | parent | prev [-]

Making a git commit typically doesn't require any special permissions or credentials since it's all local to the machine. You could do something like running the agent as a different used and carefully setting ownership on the .git directory vs. the source code but this is not very straightforward to set up I suspect.

	▲	SoftTalker a day ago \| parent [-]
		IMO it should be well within the capabilities of anyone who calls himself an engineer.