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 40 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?