Samuel Arendt

Fail-closed changes the governance model for Claude Code

Claude Code 2.1.92 added a setting with an unusual consequence for a development tool. forceRemoteSettingsRefresh can prevent the CLI from opening when it cannot fetch the organization's remote policies. The session ends without an update. It does not continue with old cached rules or offer a degraded mode for the user to decide later.

This behavior exchanges local availability for policy certainty. The choice fits environments where the risk of an agent running with stale permissions exceeds the cost of interrupting work. It also shows why deploying an agent across a company requires different controls from an individual installation.

The release also introduced disableSkillShellExecution, which blocks shell commands started by skills and plugins, and increased MCP result persistence to 500,000 characters. All three changes address one tension: agents need context and tools to be useful, while every capability enlarges the surface an organization must govern.

Fail-closed is an operational decision

Fail-open systems keep running when a control mechanism fails. That preserves availability but accepts a period with potentially outdated policy. Fail-closed systems block operation until rules are confirmed. Security increases together with a new dependency: the service delivering configuration becomes part of the critical path.

Enabling the option without preparing operations merely moves the incident. A network, DNS, authentication, or endpoint outage could stop dozens of engineers at once. The team must monitor the configuration service, set availability objectives, and distinguish a legitimate block from a control-plane failure.

First access also needs planning. New machines, ephemeral runners, and sandboxes begin without trusted state. If remote policy is mandatory, authentication and connectivity must exist before the agent starts. Onboarding documentation should treat them as requirements rather than later troubleshooting.

Blocking skill shell execution reduces transitive trust

A skill may look like an instruction file while carrying command execution. Plugins can combine guidance, scripts, and external integrations. When an engineer installs such a package, the organization inherits trust in its author, repository, update mechanism, and every dependency used by the script.

disableSkillShellExecution provides a central boundary. The agent can still read instructions, while the part able to execute on the system receives an explicit restriction. A company can allow extensions for coding standards and documentation without automatically authorizing local actions.

The control does not remove every risk. A malicious instruction may try to persuade the agent to use another authorized tool. File, network, secret, and command permissions remain necessary. The setting removes one execution route and simplifies review, but it does not replace a sandbox or allowlist.

More persistent context still needs limits

Raising MCP result persistence to 500,000 characters prevents truncation of schemas, configuration dumps, and extensive queries. An agent can consult that material later without repeating a call. Technical investigations gain continuity and retain evidence.

Two questions accompany the gain. First, does the result contain a secret, personal data, or information from another environment? Persistence expands the duration and locations in which the content may appear. Second, does the volume help? Half a million irrelevant characters can harm context selection and raise cost.

MCP servers should return only required fields, paginate large collections, and mark sensitive content. A higher ceiling solves truncation; it does not replace a careful response contract.

A minimal corporate rollout

Before requiring remote refresh, an organization can run a small pilot. Tests should cover lost connectivity, expired credentials, unavailable endpoints, and invalid policy. Each scenario needs a message that lets support identify the cause without asking users to disable the control.

Policies should then be divided between universal rules and repository-specific settings. Secret and execution restrictions can be global. Build commands and allowed paths belong closer to the project. One enormous central configuration becomes difficult to review and may block legitimate work without explaining why.

Logs finally need the applied policy version, time of the last update, and reason for a block. Governance that only prevents a session creates tickets; observable governance supports an audit.

Fail-closed mode signals product maturity and creates an obligation for the company enabling it. The organization can state that no session began outside its current rules. In return, it must operate policy distribution as part of engineering infrastructure.

If your company is weighing something similar, reach me on LinkedIn or WhatsApp.

References

#AI Agents, #Architecture, #Operations, #Radar