The security model
Anything that can log in to VCode runs code as your user on that machine. The agents work without asking for approval, so a login is full trust. VCode's security is about who can log in, not about limiting what a logged-in session can do.
Why you would use it
Before you open VCode to the internet or pair a phone, you should know what a login is worth and what stands in front of it.
How to use it
- Keep the login token secret. Treat it like the password to a shell on the machine: if it leaks, change it and restart VCode, and every browser has to sign in again.
- Leave VCode listening on the machine itself, and reach it from outside through one gate you control: a private network or a tunnel with its own sign-in, or your VCode account.
- Pair only your own devices, and remove a device you no longer use from Settings.
What you see
- A browser that is not signed in sees the sign-in card and nothing else.
- A signed-in browser or a paired device sees every thread, the shell and the files, and can do anything you can do in a terminal.
Limits and known gaps
- Login is full trust. There is no read-only mode, no permission per thread and no sandbox. A session opens a shell, reads and writes any file your user can, and runs any command.
- A session changes files directly, not only through an agent. It can edit, create, rename and delete files in any folder your user can write. A folder is deleted with everything in it, and there is no trash.
- Anything running in a thread, including the agent, can talk to VCode as you.
Related
- log-in-with-the-token — signing in on a new device
- reach-it-from-a-phone — the Access gate in front
- sign-every-device-out — revoking a session
- approvals-are-bypassed — why login is full trust
- shell-mode — the shell a session opens
- edit-a-file — the file writes a session makes
- manage-files — create, rename and delete from the explorer
- todo-list — an agent in a thread talking back to VCode