Keep Your Coding Agent in the Project: A Solo-Operator Sandbox Checklist

You ask a local coding agent to fix a failing test. It starts reading your home folder, then a sibling repo, then a script that touches a cloud key. You stop it before the damage, but the hour is gone.

For a one-person stack, the durable control is a per-project fence around files, network, and credentials. Sandboxing is a control you can test. A solo operator does not have a security team, a pager, or a second pair of eyes. The cost of a bad command is measured in hours: cleanup, rewrites, lost trust in the tool.

The local fence is the first control

If the agent can read your home directory, it can find keys, notes, and old scripts. Writing outside the project lets one bad command touch files you did not ask it to touch. A per-project boundary matches the task. The agent does not need your whole laptop to fix a test in one repo.

Copilot local sandboxing arrived in the GitHub Copilot app on September 23, 2026. The feature is in public preview, so expect rough edges. It works on macOS, Linux, and recent Windows 11 builds. It uses Microsoft eXecution Container to apply isolation policies through each operating system's native mechanisms. The app and the CLI keep their sandbox settings separate, so a change in one does not change the other.

Network and credentials are the weak points

Test runs should not have open outbound access by default. Outbound access is a direct path from a local test to a remote problem. A blocked request should fail clearly enough that you notice. After Copilot CLI reached general availability in March 2026, a crafted command could evade the CLI's read-only allowlist and download and execute an external payload without a confirmation dialog.

Keep repository and cloud credentials off until a task needs them. Credentials should be opened only for the exact task that needs them. Tokens left available can be used by a command you did not review. GitHub Actions-based AI agents, including Copilot Agent, can be manipulated through Comment-and-Control attacks to send API keys and access tokens out through GitHub infrastructure, bypassing three runtime security layers. An agent that can read your API keys can also send them somewhere you did not intend.

The cloud side has its own fence

GitHub's Copilot Workspace reached general availability and adds an Agent Sandbox that runs each task in a temporary Linux container, so repository changes wait for a reviewer's merge. The Copilot app gives each session its own git worktree, an isolated branch copy, so parallel sessions do not share one working tree. Its cloud agent asks for approval before each write by default, and an autopilot option is available only after teams have established trust. Those controls do not replace a local fence.

The checklist is the test before the next session

Use it as the minimum pass for a solo laptop. It checks the boundary you want the agent to respect. The margin comes from knowing what the agent cannot touch. The list stays short because the risk is ordinary. Quick checking beats long cleanup, rewrites, and lost focus after a bad command. Each item should take about a minute to check. If an item fails, stop and fix the permission before the next task.

• Enable the per-project Sandbox new sessions option for future local sessions.
• Deny the agent access to your home folder, personal documents, and sibling project folders.
• Cut outbound network for test runs, then verify a blocked request fails.
• Keep repository and cloud credentials off until a task needs them.
• Use /sandbox on for a one-off session when you need isolation without changing the project default.
• Run one denial test after every tool, model, or permission change.