I've been successful with getting incus running with this for sandboxing the opencode session. I plan on writing a blog post on it.
This might interest you (disclaimer my project. Well mostly Opus')
Slightly safer vibecoding by adopting old hacker habits
31–40 of 110 posts
Re: Slightly safer vibecoding by adopting old hacker habits
#32[dead]
Re: Slightly safer vibecoding by adopting old hacker habits
#33Generally a good idea, but I'm not sure why you should even want to fork a git repo when a local clone should be sufficient. But this is probably a terminology mixup from the way github presents forks and clones.
I believe the author's idea is to do dev work from a Github account that only has access to the fork, but not to the main repo. Then, as a contributor, you'd open PRs from your fork to the main repo. I think this would only work if your Github account doesn't have write access to the main repo, though. I know you can use 'deployment keys' to give read-access to a single repo using an SSH key, but not sure if you can…
On a GitHub project, agents must just be considered untrusted external contributors.
Re: Slightly safer vibecoding by adopting old hacker habits
#34the old hacker trick of using ssh
Ten more years and our tricks become the ancient practices and rituals of the olden hack0rs; stuff like apt update and apt upgrade on a fresh server. Some of the most ancient even use apt-get, while the really old ones will scold you for using Ubuntu
Re: Slightly safer vibecoding by adopting old hacker habits
#35...and proxy your llm traffic with your own per session tokens – if it leaks, it doesn't matter, not a real token.
Re: Slightly safer vibecoding by adopting old hacker habits
#36I would guess OpenAI Codex and Claude Code are well into the millions subscriber range at this point. I would venture to guess the majority of them run in yolo mode. I have only seen a few horror stories on reddit. The same way any time you drive a car you can crash and die (many times through no fault of your own). All that said, no way in hell I’m giving either access to production databases or environments.
[dead]
Re: Slightly safer vibecoding by adopting old hacker habits
#37I would guess OpenAI Codex and Claude Code are well into the millions subscriber range at this point. I would venture to guess the majority of them run in yolo mode. I have only seen a few horror stories on reddit. The same way any time you drive a car you can crash and die (many times through no fault of your own). All that said, no way in hell I’m giving either access to production databases or environments.
I have heard of more than a few horror stories including filesystems lost and force pushes done.
These tools have only been in use for a short time and the current harnesses/system prompts are quite limited. Claude code is mostly limited to your codebase where you have version control. Excel is different.
I foresee that once people hand over more power to full agents there will be some nasty surprises. Im sure there will eventually be demand for some kind of limits
Re: Slightly safer vibecoding by adopting old hacker habits
#38the old hacker trick of using ssh
Ten more years and our tricks become the ancient practices and rituals of the olden hack0rs; stuff like apt update and apt upgrade on a fresh server. Some of the most ancient even use apt-get, while the really old ones will scold you for using Ubuntu
Hey! I resemble that comment :-P
(I still tend to use apt-get out of habit...)
Re: Slightly safer vibecoding by adopting old hacker habits
#39My other Mac mini is the cloud ;)
Re: Slightly safer vibecoding by adopting old hacker habits
#40I would guess OpenAI Codex and Claude Code are well into the millions subscriber range at this point. I would venture to guess the majority of them run in yolo mode. I have only seen a few horror stories on reddit. The same way any time you drive a car you can crash and die (many times through no fault of your own). All that said, no way in hell I’m giving either access to production databases or environments.
Yeah, I was thinking about simonw's lethal trifecta[0] and how to solve it and my conclusion was "you cannot", i.e. you just accept a certain level of risks for the rewards it offers.
The "agent never sees keys" approach prevents key exfiltration, but it doesn't prevent agent from nuking what it has access to, nor prevent data exfiltration.
The best advice I heard to protect against prompt injection was "just use Opus" ( ... which was great advice before they lobotomized it ;)
But even without injection, most of the horror stories are from random error, or the AI trying to be helpful (e.g. stealing your keys or working around security restrictions, because they trained or to really want to complete a task.[1])
tl;dr yolo
[0] https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
[1] https://www.reddit.com/r/ClaudeAI/comments/1r186gl/my_agent_...