Security boundaries

Understand the workspace, command, auth, and sandbox boundaries of the runtime.

Security boundaries

Coding Tools MCP is a coding tool server. It adds workspace path checks, command safety gates, optional filesystem confinement, authentication for remote HTTP, and environment filtering. It is not a complete security sandbox by itself.

Workspace boundary

Direct file tools resolve paths under the configured workspace root. Start the server with the smallest useful workspace:

coding-tools-mcp --workspace /repo

Avoid pointing the workspace at a home directory, filesystem root, or directory that contains unrelated secrets.

Command boundary

exec_command can run arbitrary local commands allowed by the active permission mode. Treat it as code execution inside the configured workspace and process environment.

Mode	Boundary
safe	Adds policy gates for network-looking commands, shell expansion, inline scripts, sensitive environment, and broad temp writes. Landlock is enabled when available.
trusted	Allows common development workflows while retaining workspace path policy, secret filtering, and Landlock when available.
dangerous	Disables command permission gates and Landlock. Use only inside an external sandbox.

Landlock is host-dependent

On Linux, the server uses Landlock when available. If the kernel or host configuration does not support it, the server reports that command execution is running with policy checks only. That warning means you should rely on an external container, VM, or other sandbox for untrusted commands.

Authentication boundary

HTTP loopback can run without auth. Non-loopback binding requires Bearer auth, OAuth mode, or explicit CODING_TOOLS_MCP_AUTH_MODE=noauth.

For remote access:

• Use Bearer auth or OAuth.
• Put the endpoint behind TLS.
• Keep tokens and OAuth secrets out of logs.
• Set CODING_TOOLS_MCP_SERVER_URL when OAuth is behind a proxy or public tunnel.
• Avoid no-auth remote mode unless another trusted layer enforces authentication.

Environment boundary

In safe and trusted modes, secret-looking environment variable names and values are filtered from command execution. Risky loader and startup variables such as dynamic library preload and language startup hooks are also treated as unsafe.

Do not pass API keys, private keys, tokens, or credentials through exec_command.env unless the deployment and permission mode are intentionally designed for that risk.

Tool profile boundary

--tool-profile read-only reduces exposed tools but does not transform the server into an auditing system. It hides mutating tools from the client. It does not protect against every possible risk if the server is reconfigured or another client connects with a broader profile.

compat-readonly-all is a compatibility mode. It can advertise mutation-capable tools as read-only, so do not use it as a security control.

Recommended deployment posture

• Local single-user editor integration: stdio or loopback HTTP, safe mode first.
• Trusted local development automation: loopback HTTP or stdio, trusted when commands need network or shell features.
• Remote workspace: HTTP with Bearer auth or OAuth, TLS, narrow workspace, and container or VM isolation.
• High-risk automation: external sandbox first, then choose the minimum tool profile and permission mode that works.