How to Limit a Coding Agent’s Shell and MCP Server Access to the Project Directory

When you use a coding agent to edit a project, it can run shell commands and connect to local tools. The computer account that starts the agent gives its commands and tools their file access. Starting the agent in the project folder alone does not limit that access to the folder.

Use an enforced sandbox or container to limit what the agent’s processes can read and write. A sandbox is an operating-system restriction on a program’s access to files or network resources. Configure each local MCP server, a separate program that gives the agent tools through the Model Context Protocol, to expose only the project paths it needs. Approval prompts let you review actions, but they do not enforce a filesystem boundary.

Restrict the shell at the process boundary

Start the agent in the project directory, enable its shell sandbox, and inspect the rules that take effect. Make project files read-only when the task only requires inspection. Give the agent write access to the project when it must edit files. Block access to unrelated directories. Add temporary or developer-tool directories only when a specific command needs them.

The sandbox must also restrict child processes, which are programs launched by an allowed command. Otherwise, that command could start another program with broader access. Sandbox features vary by product. VS Code documents that its sandbox can cover child processes and locally managed MCP and language servers. Its default settings allow network and developer-tool access. Check the settings for your agent and host; turning on a sandbox does not automatically set the narrowest restrictions. VS Code’s sandbox documentation describes those settings. OpenAI’s Codex SDK offers named access presets, including read_only, workspace_write, and full_access. These names describe Codex settings, not a standard for all coding agents. Codex SDK’s sandbox guidance explains how its presets work.

Approval prompts and isolation address different risks. A prompt asks you to authorize an action. Isolation limits what the action can reach, even if the agent or a command makes a mistake. Keep prompts that help you review sensitive actions, and use enforced restrictions to set the boundary. Anthropic describes filesystem and network isolation as separate protections in its Claude Code sandbox design.

Confine each local MCP server

Set an explicit project path for every filesystem MCP server. For example, the maintained MCP filesystem server accepts allowed directories when it starts and supports a read-only mode:

mcp-server-filesystem --read-only /absolute/path/to/project

If the agent needs to edit files, omit --read-only and allow access only to the project directory. The server’s documentation says read-only mode removes tools that can write files. The filesystem server README documents these options.

A server-level path allowlist limits access only when the server follows its configuration. It cannot stop a compromised or buggy server from using other access the host grants it. The MCP local-server security guidance recommends isolating local servers and exposing only the paths they need. To restrict access further, run a third-party server in a container or operating-system sandbox and mount only the project directory. A read-only bind mount uses this pattern:

--mount type=bind,src=/path/to/project,dst=/projects,ro

If the server must edit the project, mount the project as writable. Keep the home directory, SSH keys, credentials, and unrelated repositories outside the container. Check the exact mount options for your container runtime.

Limit network access and credentials separately

A filesystem boundary around the project does not stop the agent from sending readable data over the network. Disable outbound network access when the task does not need it. If the agent needs network access, allow only the destinations the task requires. Do not put long-lived credentials in environment variables or files the agent can read. Sandbox products set network and filesystem rules separately, so inspect both.

Narrow permissions can block legitimate work. A build tool may need to write to a temporary directory, or a package installer may need a network connection. Add the specific path or destination the command needs instead of allowing unrestricted access by default. If you cannot identify the required access, run the command in a more controlled environment and inspect what it tries to reach.

Verify the boundary before relying on it

Test the restrictions by deliberately trying to read and write outside the project. Confirm that the sandbox or container blocks access; do not rely only on a refusal from the agent or an MCP tool. Include paths that use symbolic links, which point from one filesystem location to another. Also check how your environment handles differences in path capitalization.

This check matters because an MCP filesystem server advisory documented a path-boundary bypass. The issue involved a symbolic link on a case-insensitive filesystem and a path with different capitalization. It affected specific server versions and conditions, so it does not establish a universal bypass. It does show why a server’s allowlist needs a separate process boundary behind it. Review the filesystem server advisory, pin server versions, and check security advisories before updating.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com