We need sandboxing for any agent, so we run it within Docker - so we use CLI.
replyI use vscode with containers extensively. Not sure why containers imply CLI.
replydo you run vscode in the container ? if so, can you share your config ?
replyi've been trying to do this with systemd-nspawn
Easiest way to do it would be enable ssh in container and then use VSCode ssh extension. Your host VSCode “becomes” your container VSCode.
replyI run it natively on my rocky8 container with UI sometimes but usually just do ssh
I use the Claude Code VSCode plugin for 80% of my work.
replyI prefer it because I can look at the code (although not as often anymore) and config (very often!) easily.
It also lets me jump to previous conversations easily.
There are a few cases where the CLI makes sense. One big one is if you are running multiple simultaneous sessions on a remote server using Tmux to have them preconfigured when you reconnect is nice.
Bun in general I don't see the benefit either.
You can look at the code in editor or IDE even when CLI agent is doing work.
replyI do that when I want to, but for me using agents in IDE is like looking with one eye covered.