Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
171–180 of 200 posts
Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#172Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#173Earlier quoted context omitted.
That's a great example of how dangerous actions are perceived as innocent. The entire model of approving specific commands is absolutely bonkers. npm run build = run an arbitrary shell command written in package.json Meanwhile the agent could have done any of the following without approval: - edited `package.json` to contain any arbitrary build command - planted malicious code in `build.js` (called by `npm run build`…
What would a better system look like?
Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#174I got "overblocked" for this one: rm -rf node_modules && npm install but actually if you're only removing `node_modules` and you have a working package-lock.json already, what you want is `npm ci`; `npm install` can mutate package-lock.json and potentially expose you to supply chain attacks. If you use `npm ci` I think you don't need to `rm -rf node_modules`, either. Anyway you should generally run `npm ci` except wh…
thanks for the pointer! renamed it to npm ci so it's still 'safe'
Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#175Earlier quoted context omitted.
Literally anywhere else! Your dotfiles should be publishable to github. If they aren't you're doing them wrong. A good thing to do is organize. You can actually load different files. Here's a pretty common pattern that you'll find and it'll illustrate how to do other things if [[ $(uname) == "Darwin" ]]; then source "${INSERT_SOME_DIR}/osx.zsh" elif [[ $(uname) == "Linux" ]]; then source "${INSERT_SOME_DIR}/linux.zsh…
You’re just splitting your dotfiles into a public and a private part. That’s useful if you want to publish the public part on GitHub, but not everyone wants to do this, and the issue of storing secrets in plain text files remain.
> You’re just splitting your dotfiles
Ummm... yes? That is what I said > the issue of storing secrets in plain text files remain.
Ummm... kinda? The problem was that reading an rc file was considered dangerous. Not putting keys in your rc files is an improvement. Encrypting them is even better than that. But I also said more words in the original post and you don't really even need to read between the lines to figure out I said "you can generalize this", especially when there's comments next to it saying "here's how you load an encrypted file"Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#176Fun 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.
Where would you put them?
Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#177Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#178Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#179Earlier quoted context omitted.
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.
I'm not sure, maybe the fact that whether a given command is safe or not is subtle, contextual, and contested actually bolsters the point the game is trying to make.
Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#180About three quarters of the "bad" choices are things that not only do I not care about leaking but things that an employer would not punish you for doing, even if it led to a production incident.