When Claude Code or Codex runs on a device outside an OpenShell sandbox and works in, or touches, a confidential location, Swif reports or blocks the action. If the action is blocked, the agent is told to run inside OpenShell instead. Inside a sandbox, the Swif OpenShell Sandbox Policy controls which files, hosts, and model endpoints the agent can reach.

Important: This policy is a guardrail against mistakes, not a security boundary. It catches agents that are accidentally run outside OpenShell on confidential work. It doesn't stop a user who deliberately works around it, such as a user with root or administrator rights, or an agent that Swif can't hook.

Agents running inside an OpenShell sandbox aren't affected by this policy.

A location is confidential when any of these is true:

Folders in Exceptions are never blocked, even when they're confidential.

An action counts when the agent's working directory is in a confidential location, or the action names a file or folder there.

Not detected: paths built while a command runs, for example through a variable or a subshell. This is one reason the policy is a guardrail, not a security boundary.

Blocking only makes sense if there's a sandbox to move to. If When An Agent Works Outside OpenShell is set to block, but the OpenShell Sandbox Policy isn't assigned and enabled on the device:

The OpenShell Sandbox Policy doesn't apply on Windows, because OpenShell runs there only inside WSL 2. On Windows devices, the policy still runs and logs, but with block, matches are reported, not blocked, and the device is flagged.

Start with log. It shows what would be blocked without interrupting anyone. Review the reports, add any exceptions you need, then switch to block.

Paths for each operating system. Use /path for macOS and Linux, and C:\path or \\server\share for Windows. Each device uses only the paths written for its own system, so one policy can hold both. Paths must be absolute, can't contain .., and can't be /.

Repository format. Use host/owner/name, for example gitlab.example.com/team/project. GitLab subgroups add parts between owner and name, such as gitlab.example.com/team/subgroup/project. Use * as the last part to cover every repository under an owner, for example gitlab.example.com/team/*.

Marker file. Teams can mark a folder as confidential by adding the marker file, without asking an admin to change the policy. For example:

Folders that are never blocked, even when they're confidential. Each exception needs:

You can add up to 64 exceptions.

Every action on an example-corp repository outside OpenShell is reported, but nothing is blocked. Use the reports to find teams that need help moving to OpenShell.

The OpenShell Sandbox Policy is also assigned to the same devices. Agents working on finance folders or repositories outside OpenShell are blocked and told to use OpenShell. The public reports folder is never blocked.

If an agent hook can't read the policy, the action is blocked instead of allowed. Use this only after the policy has been stable on your devices, since a problem reading the policy would block agents.

Turning off Enabled, or unassigning the policy, removes only what Swif installed for this policy. Agents can then work on confidential locations outside OpenShell again.

The agent was started in a confidential folder. When the working directory is confidential, every tool call is caught, including calls that use files elsewhere. Start the agent outside the confidential folder, or run it inside OpenShell.

The path was probably built while the command ran, for example through a variable or a subshell. The policy only sees paths written in the command itself.

This policy only applies outside OpenShell sandboxes. Confirm that the agent is running inside a sandbox, and check the device's report for details.

Block When The Policy Cannot Be Read may be on, and the agent hook can't read the policy on that device. Check that the Swif agent is running, or turn the setting off.

Swif

NVIDIA