The Swif OpenClaw Tools Runtime Policy controls how OpenClaw runs commands, detects repetitive tool activity, and handles files attached to spawned sessions on managed devices.

Use this policy to:

This policy changes runtime behavior. It does not grant an agent access to a tool that is denied by the Swif OpenClaw Tools Access Policy.

Important: Runtime settings can affect agent reliability, resource use, and access to local files. Test changes with a small device group before broad deployment.

OpenClaw controls are most effective when access, runtime behavior, and audit visibility are managed together.

For example, enabling Apply Patch in this policy does not make the tool available if it is denied by the Tools Access Policy. Access rules remain authoritative.

The Swif policy does not prepopulate a default configuration. A setting that you leave unconfigured is omitted from the policy, allowing the installed OpenClaw version to use its own default behavior.

At the time of publication, OpenClaw documents the following native defaults:

OpenClaw can change defaults and schema names between releases. Review the OpenClaw configuration reference and the live schema on the managed device before changing advanced settings:

Two naming differences deserve particular attention:

The Swif agent is expected to translate policy fields to the applicable OpenClaw configuration. Confirm the effective behavior on every OpenClaw version you approve for production.

For general assignment instructions, see Assigning policies to devices or groups.

Exec settings control command lifetime, background behavior, completion notifications, output presentation, and access to apply_patch.

Specifies how long OpenClaw waits before moving a running command to the background.

The value is measured in milliseconds. For example:

Moving a command to the background does not stop it. The agent can continue to monitor the process through the applicable process-management tool when that tool is allowed.

Specifies the maximum command runtime in seconds. OpenClaw stops a command that exceeds the configured limit.

Choose a timeout long enough for approved builds, package operations, and security scans, but not so long that a stalled process consumes resources indefinitely.

The timeout should normally be greater than the background delay. For example, a 10-second background delay and a 30-minute timeout would be entered as:

Compatibility note: Current OpenClaw documentation calls the native setting timeoutSeconds. Verify that the installed Swif agent and OpenClaw release apply the value correctly.

Specifies how long OpenClaw retains completed exec output before cleaning it up. The value is measured in milliseconds.

This controls runtime output cleanup. It is not an organizational log-retention policy and should not be treated as a replacement for security logging or centralized audit storage.

When enabled, OpenClaw sends a notification when a background process exits.

Enable this setting when agents must know that a build, scan, installation, or other background operation has finished.

When enabled, OpenClaw also sends an exit notification when a background process completes successfully without producing output.

Leave this disabled if empty success notifications create unnecessary activity. Enable it when silent processes are operationally important and their successful completion must be visible.

Enables syntax highlighting for exec output. This is a presentation setting and does not change command permissions or execution behavior.

Controls OpenClaw's apply_patch capability.

apply_patch can modify files by applying structured patches. Because it can change source code, configuration, and other local content, enable it only for workflows and models that require file editing.

For least-privilege deployments:

Loop detection helps identify repeated tool activity that is not making useful progress. It can warn an agent, block a repeated tool batch, and eventually stop a run that remains stuck.

OpenClaw documents two related safeguards:

The rolling-history detectors are disabled by default in current OpenClaw documentation. The post-compaction guard can remain active when the main loop-detection setting is unset. Explicitly disabling loop detection can disable both safeguards, depending on the installed OpenClaw version.

OpenClaw recommends enabling rolling-history detection for smaller or less capable models. Regardless of model size, test the setting against representative workflows because legitimate polling, retries, and iterative tasks can resemble a loop.

When you configure thresholds, keep them in increasing order:

Do not copy threshold values from an older OpenClaw release without validation. The current public documentation does not define authoritative defaults for these advanced fields. Leave them unconfigured to inherit the installed gateway's behavior, or confirm supported values with openclaw config schema before deployment.

Disabling an individual detector can reduce false positives for a known workflow, but it also removes protection for that pattern. Prefer adjusting a workflow or its thresholds before broadly disabling safeguards.

For more detail, see OpenClaw tool-loop detection.

These settings control files passed to sessions created through the session-spawning tool.

Attachments are disabled by default. Enable them only when a spawned session must receive a file to complete its work.

Use byte values rather than display units:

Ensure Max File Bytes is less than or equal to Max Total Bytes.

OpenClaw materializes subagent attachments in a session-specific directory under .openclaw/attachments/ and creates a manifest for them. Current OpenClaw documentation states that attachment content is redacted from transcript persistence, directories use restrictive permissions, and files are removed when the session is deleted. However, the receiving agent can still read the attachment while it is available. Do not attach secrets or regulated data unless the workflow, model, storage, and logging controls are approved for that data.

For ACP-based spawned sessions, current OpenClaw documentation limits attachments to images. A rejected non-image attachment may therefore be expected behavior rather than a policy installation failure.

For organizations that need attachments, begin with a narrow limit:

Adjust these limits only after reviewing the file types and sizes required by the workflow.

The following configuration is a practical starting point for a pilot. It preserves familiar command behavior while applying explicit least-privilege choices.

This is a starting point, not a universal security standard. Shorter timeouts can disrupt legitimate builds or scans, while longer timeouts increase the impact of stalled or unintended commands.

Use the following settings for workflows that may continue after the interactive response:

A command moves to the background after 10 seconds and can continue for up to 30 minutes. Completed output remains available for up to 30 minutes.

Replace the placeholder with the exact model identifier approved by your organization. Model aliases and identifiers can change, so validate the list after model or OpenClaw upgrades.

Leave the history and threshold fields unconfigured during the initial deployment. This avoids hard-coding values that may not match the installed OpenClaw release.

This permits up to ten files, limits each file to 1 MiB, and limits the entire request to 5 MiB.

After assignment:

Use non-production files and harmless commands for verification. Do not deliberately create an uncontrolled process or destructive file-editing test.

For broader deployment guidance, see Getting Started with Swif's Agentic Security for Enterprise.

Check the following:

Compare the policy with the live output from:

Pay particular attention to the timeout and spawned-session key names described under Defaults and Version Compatibility.

Increase Background Ms. This setting affects when the command becomes asynchronous; it does not increase the maximum runtime. Increase Timeout Sec separately if the command is also being stopped too early.

Increase Timeout Sec after confirming the command is expected and safe. Also check whether an operating-system service, endpoint security tool, resource limit, or user action terminated the process.

Confirm that:

If the command succeeds without output, enable Notify on Exit Empty Success for the test.

Confirm that:

Identify which detector matches the workflow. Repeated polling commonly affects Known Poll No Progress, while alternating calls can affect Ping Pong.

First, reduce unnecessary retries or add progress between calls. If tuning is still necessary, increase thresholds gradually on a test group. Disable an individual detector only after reviewing the resulting loss of protection.

Confirm that Enabled is explicitly enabled for rolling-history detection. An unset value can leave only the post-compaction safeguard active. Also confirm that the relevant detector is enabled and that the configured thresholds are supported by the installed OpenClaw version.

Confirm that:

Confirm the Retain on Session Keep value and the workflow's cleanup mode. Disable retention if kept sessions should not preserve materialized attachments, then validate the behavior with a new test session.

To change the runtime configuration:

To stop managing these settings:

Removing an assignment does not always guarantee that a previously written application setting returns to its earlier value. Test policy removal before relying on it as a rollback method.

The Swif OpenClaw Tools Runtime Policy gives administrators a central way to manage command execution, file-patching controls, loop safeguards, and spawned-session attachments across enrolled macOS, Windows, and Linux devices.

For a safe initial deployment: