3 ms·
I'm curious about the opposite: Why would anyone use the CLI when, at least with Copilot, the VSCode plugin is super tightly integrated with VSCode, meaning the
by 0xffff2 5mo ago
I'm curious about the opposite: Why would anyone use the CLI when, at least with Copilot, the VSCode plugin is super tightly integrated with VSCode, meaning the agent can see everything I can see. There's no mismatch in linter calls where I can see a lint in the ide that the agent can't find for example. I've had this problem even using CC in their VSCode extension, so I can't imagine it's not an issue in the CLI as well.
What's actually better in the CLI?
- sz4kerto 5mo agoWe need sandboxing for any agent, so we run it within Docker - so we use CLI.
- 0xffff2 5mo agoI use vscode with containers extensively. Not sure why containers imply CLI.
- nqzero 5mo agodo you run vscode in the container ? if so, can you share your config ? i've been trying to do this with systemd-nspawn
- chris_money202 5mo agoEasiest way to do it would be enable ssh in container and then use VSCode ssh extension. Your host VSCode “becomes” your container VSCode. I run it natively on my rocky8 container with UI sometimes but usually just do ssh
- nl 5mo agoI use the Claude Code VSCode plugin for 80% of my work. I 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.
- krzyk 5mo agoYou can look at the code in editor or IDE even when CLI agent is doing work. I do that when I want to, but for me using agents in IDE is like looking with one eye covered.