Live data from Hacker News

Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

llmgame.scalex.dev

161–170 of 200 posts

Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

#161

Claude Code has gotten so bad about this that I’ve stopped using it for code reviews. I may look into wiring Claude up to Codex as an alternative LLM just to compensate. I think the issue is that I’m running Claude Code in a container so it sees that it is root, and becomes a lot more cautious. Not sure, though.

If you're running Claude Code in a container anyways, why does `--dangerously-skip-permissions` not work for you?

Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

#162
post #99

A bit too JavaScript specific... can't really play if you don't know that ecosystem.

It suggests that "kill $(lsof -t -i:3000)" is completely safe, which it's not, if you don't know what runs on that port. Maybe some Javascript framework runs on that port, I don't know, but neither does the AI, the developer may have moved it, because something important runs on that port already.

Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

#164
post #94

The permission thing is a killer to productivity, if you're running Claude I think it's more efficient to just run in a disposable sandbox (like exe.dev[1]) or in some form of docker container with permissions you're personally ok taking the risk with on a personal machine[2] [1] - https://exe.dev/ is a new cloud provider with some very useful agent UX [2] - I built https://github.com/stanislavkozlovski/dclaude/ for…

A disposable sandbox wont protect you from secret exfiltration. Assuming you don't consider your code a secret, you could of course set up your sandbox so it doesn't have any secrets, but that would severely limit the kinds of tasks you can use the agent for.

Are we just talking about API calls to providers? If so, wouldn't local agent + sandbox solve all that?

Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

#168
post #72

Weird to make reading zshrc supposed unsafe when I happily publish it in my public dotfiles repo... Who the hell keeps API keys in it? OTOH it seems like lots of these AI tools keep appending PATH in it so I guess there's a fundamental misunderstanding of shell best practices in the entire AI space... Additionally, killing the results of `lsof` is _not_ safe - if, say, you have the web page open in firefox, or a clie…

Yeah, the game seems to assert that the kill is safe to run because Claude told me it was safe. But that's the point, I'm not supposed to trust Claude.

Likewise I got dinged for denying a random stash-rebase-pop operation. I have no idea what the repo state is like right now. That could be a wild mess of a waste of time. It says I'm doing a refactor, so OK I guess rebase on main is a good idea. But hell no I'm not approving that in the 1 minute before a meeting.

The whole premise IMO is pretty flawed. It's interesting as an ad for the company though.

Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

#169

Claude Code has gotten so bad about this that I’ve stopped using it for code reviews. I may look into wiring Claude up to Codex as an alternative LLM just to compensate. I think the issue is that I’m running Claude Code in a container so it sees that it is root, and becomes a lot more cautious. Not sure, though.

If you're running Claude Code in a container anyways, why does `--dangerously-skip-permissions` not work for you?

Claude Code won't let you do that as root. Codex's equivalent is perfectly fine, though.

Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

#170

Fun game, but it showed the lack of security hygiene employed by the game writer. It said `cat ~/.zshrc` was bad because it would share tokens and secrets, but I would never put secrets into my shell rc.

Plenty of people would. But then I guess they're in env and probably already available to Claude

Just aside from all of the security concerns, this is the wrong place to define global environment variables for zsh in the first place! That would be ~/.zshenv. So even if you're clueless about storing secrets in plain text and exporting them as env vars everywhere, ~/.zshrc should still be clean.
Post reply on HN