Previous article：Patch Editing for AI Coding Agents: Apply Unified Diff Safely
Next article：AGENTS.md for AI Coding Agents: Load Project Rules into LLM Context
中文版：Approval 与 Sandbox：写入审批和工作区边界

Introduction

Day 12: protect coding-agent side effects with explicit approval gates and a workspace sandbox. This chapter keeps the implementation deliberately small: the point is to make one boundary explicit, testable, and easy to inspect before adding more autonomy.

Approval and sandbox solve different problems

A coding agent is more than a model response. It needs a runtime that can turn a request into controlled work, preserve the intermediate state, and explain what happened afterwards. Day 12 focuses on that runtime boundary instead of hiding it behind a single prompt.

tool request → risk classification → approval check → workspace validation → execution

A single decision point for side effects

The implementation uses explicit data structures and narrow interfaces. The model proposes the next step; the harness owns validation, execution, limits, and structured results. That separation lets the same capability work in a CLI today and in a richer product surface later.

• Classify the requested action before it reaches a handler.
• Require an explicit grant for writes and command-like side effects.
• Resolve paths against the workspace and reject escape attempts.

Rejecting path escape

Reliability comes from treating failure paths as normal paths. Inputs are bounded, unsafe or malformed requests produce recoverable errors, and the run records enough evidence to let a developer understand the decision. This is especially important when later steps can touch a real workspace.

npm run dev -- "show approval sandbox for a write"

Model proposes tool call
  -> classify risk
  -> check approval
  -> validate workspace path
  -> execute tool
  -> record result

../../.ssh/config
/tmp/agent-output.txt

Default-deny behavior in practice

With this layer in place, later chapters can add capability without weakening the boundary: tools can be registered and observed, context can be measured, writes can require approval, and every run can be replayed. The result is not a general autonomous system; it is a compact harness whose behavior remains understandable.

Key takeaways

• Build the execution boundary before adding more tools or model freedom.
• Keep model intent separate from runtime authority.
• Make limits, validation, and failure results visible.
• Use structured observations to support debugging and future extensions.

Demo

The accompanying implementation and runnable examples are available in the cli-harness repository.