11–20 of 110 posts
IM new to Claude code but doesnt auth require a gui browser to authenticate the Claude session first time login?? Do you have to setup a desktop environment just for that?
This is what yoloAI does. Automatically. # Create a new sandbox copying . as workdir (default container, but you can choose vm) yoloai new mybugfix . --isolation vm # attach to it (it has tmux already) yoloai attach mybugfix # Chat with the bot inside... # Happy with its work? Diff it to be sure yoloai diff mybugfix # Happy with the changes? Apply them to your workdir yoloai apply mybugfix # All done? Destroy the san…
This is what yoloAI does. Automatically. # Create a new sandbox copying . as workdir (default container, but you can choose vm) yoloai new mybugfix . --isolation vm # attach to it (it has tmux already) yoloai attach mybugfix # Chat with the bot inside... # Happy with its work? Diff it to be sure yoloai diff mybugfix # Happy with the changes? Apply them to your workdir yoloai apply mybugfix # All done? Destroy the san…
Spammy ai-generated self promotion.
This does the same thing as in the blog post, except that there are a LOT of gotchas and minutiae and some yak shaving involved if you want to keep doing it manually.
I've gone through the whole path the author has, and finally had to admit that it's too much fiddling around to do it manually. Easier to just have a cmdline tool that does it for you. That's why I built it in the first place.
All that said, no way in hell I’m giving either access to production databases or environments.
The downside for me and the main reason I do use vms less than I did a few months ago is that I need my agentic coding tools to use development tools a lot. And those tools need a lot of resources. And I have those resources on my laptop. Which is a nice mac book pro with plenty of RAM and 16 CPUs. I can run vms on this thing without issues of course. But tools just run a lot faster when I run them outside those VMs. And agentic coding tools run builds all the time. We're talking some really non trivial time savings here. Watching qemu build a thing for 10 minutes that I know should build in 45 seconds is painful. Especially if it happens over and over again.
The trick is doing sandboxing without performance impact. And very soon you'll also want to be able to run local models. I've been toying with the latest qwen and gemma models on my laptop. I haven't gotten around to doing coding with those just yet. But apparently they aren't completely horrible at it. That won't work on most cloud based vms. Unless you get a really big and expensive one. You could actually make that work if you only use them for a few minutes.
This is what yoloAI does. Automatically. # Create a new sandbox copying . as workdir (default container, but you can choose vm) yoloai new mybugfix . --isolation vm # attach to it (it has tmux already) yoloai attach mybugfix # Chat with the bot inside... # Happy with its work? Diff it to be sure yoloai diff mybugfix # Happy with the changes? Apply them to your workdir yoloai apply mybugfix # All done? Destroy the san…
It's a variation of sandboxing which is a great idea. Even just using a separate user account on your laptop provides some useful level of isolation (as long as you don't give it sudo privileges). AI tools of course do some sandboxing of their own. It's just that the constant nagging for permissions causes people to negate most of that by giving very broad access outside the sandbox. The downside for me and the main…
IM new to Claude code but doesnt auth require a gui browser to authenticate the Claude session first time login?? Do you have to setup a desktop environment just for that?
Earlier quoted context omitted.
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…
You could also just set the development machine up as a remote on the repo on your local host and then pull, diff, and merge locally. Then the llm agent doesn’t have access to any github account at all.
This is what yoloAI does. Automatically. # Create a new sandbox copying . as workdir (default container, but you can choose vm) yoloai new mybugfix . --isolation vm # attach to it (it has tmux already) yoloai attach mybugfix # Chat with the bot inside... # Happy with its work? Diff it to be sure yoloai diff mybugfix # Happy with the changes? Apply them to your workdir yoloai apply mybugfix # All done? Destroy the san…
The part that worries me here is the diff. Does it happen in the host or in the guest? What code gets run when you run `yoloai diff`?
The above example doesn't specify workdir mounting mode, so it would be copy, not overlay.