Live data from Hacker News

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

llmgame.scalex.dev

141–150 of 200 posts

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

#141

Earlier quoted context omitted.

A computer is only secure if it remains powered off and airgapped.

Turn off your computer and make sure it powers down Drop it in a 43-foot hole in the ground Bury it completely, rocks and boulders should be fine

Straight Outta Lynwood was a great album. One of the CDs that I took out of my case the most often as a struggling nerdling who was still a year or two away from having scrounged up enough spare cash for a secondhand iPod.

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

#142

Earlier quoted context omitted.

Turn off your computer and make sure it powers down Drop it in a 43-foot hole in the ground Bury it completely, rocks and boulders should be fine

> rocks and boulders should be fine You’re setting yourself up for a supply chain attach here if you trust whatever rocks and boulders are sitting around. A well resourced adversary may have placed power supply boulders and wifi rocks in your back yard.

I keep a large supply of thermite on-hand just to make sure that the computer is completely burned every day after it gets dropped into the pit.

Tomorrow is a new day.

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

#143

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.

Also, there's nothing inherently insecure about feeding secrets to an LLM, it's only one element of the lethal trifecta.

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

#144

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.

Having "tokens and secrets" at all is a lack of security hygiene.

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

#145
post #52

Earlier quoted context omitted.

Where would you put them?

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…

Okay. Here is a pattern i follow everywhere in my init files for almost every program. Define two key env vars. $DOTFILES and $ECORP. The first is path to your personal set of dotfiles. The second is path to your corporate specific dotfiles.

On personal pc no need to define the $ECORP var in shell init. On work pc define that var.

based alone on that you can conditionally do almost anything.

- shell source files/aliases

- vim/editors enable disable plugins based on existence of env vars.

- define shortcuts in file manager.

- and i add the following to my main $DOTFILES .gitignore.

  # Any file that contains the following will be ignored.
  # Used to ignore files in corporate environment
  *ECORP*
  *ecorp*

Based on multiple years across different setups, using environment variables was the most reliable option since I have been in places where there are restrictions on where my init files can be placed and having to change a shit ton of paths in my dotfiles or just keeping a different branch for work and personal (and making sure they stay in sync) was too much of a hassle.

Additionally, maintaining hygiene is essential, where I only use a Read Only PAT token on my personal dotfiles in workenv. That way, there is no accidental way I would be able to push from my workenv.

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

#148
post #52

Earlier quoted context omitted.

Where would you put them?

Into `pass`, for example: https://news.ycombinator.com/item?id=48108207

Just curious, any reason to prefer using age (you mentioned that you would prefer it if starting over), over something like keepass? I am currently using keepass-cli and only reason i did not use age even though i found it was that it was new to me and I never heard of it (probably not the best reason, but in this era might be a reasonable thing to stick to devil you know). So curious about your take on this.

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

#150

Love it. One nitpick. >npm config set registry https://npm.internal >Pointing npm to the company's internal registry mirror as required by onboarding docs It claimed this is safe and I was 50/50 on it but eventually rejected it. If this README is for a public / forked repo, and that https://npm.internal is actually https://npm.internal.somethinganexternaldnscanresolve.tld This can go bad really quickly... In 99% of c…

that's a good callout. .internal is a reserved TLD so it shouldn't resolve publicly, but that's a good point about being wary of changing this while letting claude refactor a project for something that's best configured separately. Moving it to permanent mutation!
Post reply on HN