The cache fix is ready for its regression test. The agent has added locale to the preview cache key, so two locales cannot share the same document's rendered output. Then the test runner reports a missing dependency. The agent proposes an installation command that tries to reach a package registry. The environment blocks the connection.

Getting the package would help the task. The harness, the code around the model, must still check whether the install may use the network, run downloaded code, or write outside the workspace. It must also limit the process that runs it.

This continues the series' document-preview repair. Four jobs keep the next step clear: instructions shape the request, permission rules check it, approval grants any needed access, and a sandbox restricts execution. A successful install still leaves the regression test to run.

Four jobs before a command runs

These are responsibilities. One system can handle several, and the user need not face four dialogs.

The four jobs can disagree. A model can follow the task well and still ask for an operation its environment forbids. A permission rule can allow a command that the sandbox blocks. A person can approve an action while the tool keeps using the old restricted environment. The harness must report what happened and which rule or restriction decided the result.

Harness Engineering supplies the series' organizing questions.

Instructions help the model choose a command

Instructions can tell the model to use the project's package manager, inspect the lockfile, and run the narrow regression before a full suite. They can prevent an unnecessary global install or speculative dependency update before any permission decision is needed.

The model can still misunderstand the task, read misleading material, or produce an incorrect command. An instruction such as “do not write outside the project” works only while the model follows it. A shell tool can still do whatever its process permissions allow.

A dependency README might recommend a global install for interactive use. The agent can read it as setup advice. The user asked for a workspace repair, and the README gives no permission to change the machine. The README's author wrote that advice, not the user. Text that arrives in a tool result carries no user permission.

The context chapter explains why the source of instructions matters. The harness should keep that source, then check the resulting action against permission rules. Knowing where advice came from helps the model read it correctly. Checking the action provides a safeguard when that reading goes wrong.

Permission rules need the exact action

A permission check looks at a tool name and arguments, a path, a command, a destination, or some combination. Its rules can allow the action, deny it, or ask for another decision. The check is only as accurate as the description of what will run.

OpenCode's official permissions documentation gives configurable allow, ask, and deny outcomes, with input-pattern rules and external-directory checks. The documentation also describes ordered rules: the last match wins. Other permission systems can use a different order.

“Run tests” is a goal. “Start this test command in this workspace under these environment restrictions” describes an action the harness can check. Installing the missing dependency is another action, with its own effects.

Write test cases next to the permission rules. For example: the project test command is allowed, the same command in another checkout is not automatically allowed, and a download still goes to the network rule. Then the model does not have to invent edge cases mid-repair.

A rule can only check what it can match reliably, such as a path or command text. Whether the regression test actually catches the locale bug is a question for code review and the test run.

A command name says little about what it does

A package manager can download archives, write an installation tree, use caches, and run lifecycle scripts, scripts run automatically during installation. What happens depends on its version and configuration as well as the executable name.

In the npm v11 npm ci reference, the command expects a lockfile, rejects certain disagreements with the manifest, and replaces an existing installation tree. Script-related options have their own rules. Calling an install “just a download” hides work it may perform. These are effects to check before an install.

Shell syntax adds more possibilities. A command can run a script whose contents were absent from the request. A wrapper can change directories or start a subprocess. A command prefix rule matches the beginning of the command text. It cannot, by itself, describe everything the process and its children will do.

A narrow allowance for a known test entry point can help in a controlled workspace. Claiming that every command starting with the same executable is safe needs much stronger justification. The permission rule's claim should match what it checks.

For the cache repair, inspect the existing setup before proposing an install. An offline dependency cache may let the same test run with the original network restrictions. If installation is necessary, explain what it will do and what extra access it needs.

An approval names the action and how long it lasts

An approval prompt asks the user to permit an action. “Allow this?” works only if the user can tell what “this” means and why the task needs it.

For the installation, name the workspace, package source, command, expected writes, and why the existing test cannot run. Distinguish a one-time action from an ongoing allowance. The prompt can be short, but “finish verification” is too vague to describe the operation.

Keep the approval attached to the reviewed action. If the tool rewrites arguments, changes the working directory, or substitutes a script, the harness must decide whether the approval still applies. Otherwise the user approves one action and the tool runs another.

An approval for this installation does not automatically cover later uploads, unrelated package upgrades, or global configuration changes. State how long it lasts: once, session, workspace, or persistent policy. Labels that hide these differences can make broad access look like a one-time grant.

Frequent prompts can tire users. Give ordinary actions predictable limits and reserve attention for meaningful changes in access. Showing the same vague prompt less often, or hiding it behind a default, does not make the decision any clearer.

A sandbox limits the running process

Permission rules decide whether an action may start. A sandbox limits what the process can reach after it starts. A system can use both checks.

Anthropic's sandbox engineering article describes Claude Code sandboxing that combines filesystem restrictions and network controls, using operating-system (OS) sandbox mechanisms and a proxy. It also discusses spawned processes. Telling the model to limit network use and mediating the process's network access are different layers of control.

Suppose the cache tests can write to the checkout and a temporary directory, with network access disabled. That allows ordinary test artifacts while blocking a registry fetch. An approved install might use a different environment with the extra access it needs. Verification can then return to the original restrictions.

A process can affect any directory mounted writable in its environment. Any secret it can read is exposed to that process, even if the task never needed it. A network allowance may expose more than one application endpoint. Check which resources the process receives before describing what the sandbox protects.

The sandbox limits process effects. The regression test checks behavior. Keep both results in the run record.

Worktrees separate files, sandboxes limit access

“Isolation” can mean several things in an agent product. A fresh conversation separates histories. A Git worktree gives a task a separate checkout. A process sandbox restricts resource access. A container or virtual machine may add further limits, depending on its configuration.

A separate worktree can prevent accidental edits to another checkout. It still leaves the package manager able to read the user's home directory or contact the network if the process environment and permission rules allow it. Describe what each mechanism protects instead of relying on the word “isolation.”

Giving a second agent fresh context may leave its filesystem permissions unchanged. Offering fewer tools may reduce what the model sees, while one broad shell tool still permits large changes. Judge a tool set by what its tools can execute, not by how many tools there are.

The coordination chapter follows this issue further. Before handing work to a subagent, the parent must know which state is copied, which resources are shared, and which permissions the child inherits. Calling it a “separate agent” answers none of those questions.

The loop must report a blocked command

A blocked registry connection tells the agent about the environment. It leaves open whether the locale patch is correct, and it gives no reason to claim a passing test or repeat the same download.

The tool result should name the denied action and the restriction that blocked it. “Network destination blocked” lets the model choose an allowed offline path, request specific extra access, run a smaller check, or report that full verification is incomplete. A generic execution error leaves the next turn guessing. The agent loop must keep those outcomes apart.

An installation may do local work before the connection is denied. Inspect its result and the relevant workspace state before retrying or changing strategy. A blocked operation may have changed files already.

Repeated failure calls for a new plan, not for removing the rule. The agent can continue unaffected analysis while an access decision is pending. It should not switch silently to a broader tool, another network route, or an environment outside the task to perform the denied operation.

A final report for the repair can be precise: the key includes locale, the regression test was added, and the selected command could not finish because the network rules left a required dependency unavailable. That preserves the changed code and the verification limit. “All done” and “nothing worked” both lose information.

Test permissions by trying the effects

A precise-looking approval prompt can hide a process with much broader access. Test what the process can do and what the sandbox blocks, as well as whether a prompt appeared.

For a small, harmless controlled fixture, try writes inside and outside an allowed directory. Connect to an allowed and a blocked local test endpoint. Launch a subprocess that repeats those checks. Verify both the result and the record sent to the agent.

Then test changes in access. Approve one declared operation and check that a different command does not inherit the approval by accident. Change the working directory or arguments and check whether the rules require a new decision. Test explicit denial separately from unavailable approval: the loop may need different explanations for them.

Finally, test what the agent does next. Does it understand the blocked network operation, keep an applied patch separate from a verified repair, and avoid repeatedly asking for the same denied action? A sandbox can enforce its restrictions while the conversation still reports the wrong result. Both affect the user.

To complete the cache repair, the agent needs permission to run the necessary commands and a test on the final patch. If verification stops, its report should explain why. Better model instructions help it choose the next action. The harness must still make clear which dependency access is allowed, what limits the process, and when the user needs to decide.

References

• Barbaste et al., Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents -- A Source-Code Study of Eleven Systems, especially the safety and permission architecture comparison.
• OpenCode, permissions documentation, checked October 22, 2026.
• Anthropic, beyond permission prompts: making Claude Code more secure and autonomous, October 20, 2025.
• npm, npm ci command reference.

Updated 27 October 2026