But good call-out if someone uses a different workflow.

The major benefit for me with this setup is that the agent can do all of the dev things that I can (install packages, build/run docker images, ...) which is a way faster loop than me trying it manually and then reporting back to the agent.

[1] https://blog.emilburzo.com/2026/01/running-claude-code-dange...

[2] https://news.ycombinator.com/item?id=46690907

Random tracklog example: https://www.xcontest.org/world/en/flights/detail:mattmozza/2...

(zoom in until you see circles on the track line)

Orange Yoxo is the only one which has actually-unlimited, all the others have a fine-print somewhere with "up to X GB/month, then bandwidth is severely throttled".

I'm using the 4.9€ plan for a mountain webcam[1] and they have been true to their word, no throttling so far.

[1] https://ignis.maramures.io/

It's pretty neat since you can have one oauth instances for all virtual hosts, e.g.:

  server {
      [...]   
     
      location /oauth2/ {
          proxy_pass       http://127.0.0.1:8469;
          proxy_set_header Host                   $host;
          proxy_set_header X-Real-IP              $remote_addr;
          proxy_set_header X-Scheme               $scheme;
          proxy_set_header X-Auth-Request-Redirect $request_uri;
      }
  
      location / {
         auth_request /oauth2/auth;
         error_page 401 = /oauth2/sign_in;
  
         [...]
      }
  }

FYI they fixed it in 7.2.6: https://github.com/VirtualBox/virtualbox/issues/356#issuecom...

- There's a cloned 'my-project' git repo on the base OS

- The 'Vagrantfile' is added to the project

- 'vagrant up', 'vagrant ssh' and claude login is run inside the VM

At this stage, besides the source code and the Claude Code token (after logging in), there are no other credentials on the VM: no SSH keys, no DB credentials, no API tokens, nothing.

There is also no need to add:

- SSH keys or GitHub tokens: because git push/pull is handled outside the VM

- DB credentials: because Claude can just install a DB inside the VM and run the project migrations against that isolated instance, not any shared/production database

API tokens can definitely be a problem if you need external service integration. But that's an explicit opt-in decision, you'd have to deliberately add those credentials to the Vagrantfile or sync them in. At that point, yes, you need proper token scoping and permissions.

> Mounting the Docker socket grants the agent full access to your Docker daemon, which has root-level privileges on your system. The agent can start or stop any container, access volumes, and potentially escape the sandbox. Only use this option when you fully trust the code the agent is working with.

https://docs.docker.com/ai/sandboxes/advanced-config/#giving...

With these powers there's a lot less back-and-forth with me running commands, copying the output, pasting it to Claude, etc.

I'm sure you've had the case where you had to instruct someone to do something (e.g. playing tech support with family, helping another engineer, etc). While it helps the other person learn, it feels soooo slow vs just doing it yourself :) And since I don't have to teach the agent, I think this approach makes sense.

Comments URL: https://news.ycombinator.com/item?id=46690907

Points: 351

# Comments: 258

> VMs with 3D acceleration

I think we don't even need 3D acceleration since Vagrant is running the VMs headless anyways and just ssh-ing in.

> Incus (on Linux hosts)

That looks interesting, though from a quick search it doesn't seem to have a "Vagrantfile" equivalent (is that correct?), but I guess a good old shell script could replace that, even if imperative can be more annoying than declarative.

And since it seems to have a full-VM mode, docker would also work without exposing the host docker socket.

Thanks for the tip, it looks promising, I need to try it out!

Yes! I'm surprised more people do not want this capability. Check out my comment above, I think Vagrant might also be what you want.

Why in the cloud and not in a local VM?

I've re-discovered Vagrant and have been using it exactly for this and it's surprisingly effective for my workflows.

https://blog.emilburzo.com/2026/01/running-claude-code-dange...

But if you need something more strict, 'config.vm.synced_folder' also supports 'type rsync', which will copy the source folder at startup to the VM, but then it's on you to sync it back or whatever.

https://www.androidauthority.com/android-15-notification-coo...

> Telegram Announces Removal of "People Nearby" Feature

So I've also been thinking for a while now: how can that style of community be recreated? There's of course the chicken-and-egg problem until you have traction, but also things like: how big should the community be, geographically? The same size in the US vs EU likely encompasses quite different amounts of people. Should it be anonymous or real identities? Should history be viewable by new members or should it be ephemeral? And so on.

Anyway, interesting prototype, I hope you get some traction!

[1] https://en.wikipedia.org/wiki/Direct_Connect_(protocol)

I always wanted a dedicated binary anyway, so 1 hour later I got: https://github.com/emilburzo/pushbulleter (10 minutes vibe coding with Claude, 50 minutes reviewing code/small changes, adding CI and so on). And that's just one where I put in the effort of making it open source, as others might benefit, nevermind the many small scripts/tools that I needed just for myself.

So I share the author's sentiments, before I would have considered the "startup cost" too high in an ever busy day to even attempt it. Now after 80% of what I wanted was done for me, the fine tuning didn't feel like much effort.