Dev.to AI πŸ€– Ai πŸ‘ 0 πŸ“– 1 min read

What I lock down before letting a coding agent run commands on my laptop

GitHub made local sandboxing for Copilot generally available this week, in the CLI, the Copilot app and VS Code Agent Host sessions. Commands the agent starts run with restricted access to files, network and credentials,

GitHub made local sandboxing for Copilot generally available this week, in the CLI, the Copilot app and VS Code Agent Host sessions. Commands the agent starts run with restricted access to files, network and credentials, based on a policy you set.

I've been letting agents run commands locally for a while, mostly with no boundary at all, so this pushed me to write down what I actually care about.

Files

The agent should see the repo it's working on and nothing else. My home folder has SSH keys, cloud configs and old project stuff. None of it helps the agent fix a failing test.

Network

Most tasks need package installs and not much more. I'd rather allow the package registry and block the rest than find out later that some script phoned home.

Credentials

This is the one that worries me. If the agent can use my Git credentials, it can push. GitHub's sandbox lets you control access to Git and GitHub CLI credentials, and that's the setting I'd look at first.

What it costs

Friction. Some installs and tests will fail inside a sandbox and you'll spend time loosening the policy. I'd expect to tweak it a few times in the first week.

What I'd skip

Writing a perfect policy up front. Start strict, see what breaks, open only that.

One detail I liked in the announcement: model execution and tool isolation are treated separately, so the policy applies whichever model you pick.

Are you running coding agents inside any sandbox yet, or just trusting the diff review at the end?

πŸ“° Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.