Agent safety: approvals, sandbox & bypass policy

Agent Dev asks before it acts. This page explains the two dials that make that true — approval policy and sandbox — and the single policy gate that decides whether anyone can switch them off.

Every Agent Dev run is governed by two settings. The approval policy decides when the agent must stop and ask you — you see the same command and patch approval prompts users know from the Agent Dev panel. The sandbox decides what the agent may touch while it works. Fresh installs run with on-request approvals and a workspace-write sandbox: the agent asks before risky commands, and its writes stay inside the workspace.

Approval policies

Approval policyWhen the agent asks you
untrustedBefore almost everything. The most conservative choice for unfamiliar repositories.
on-requestBefore commands and patches that need judgment. The default.
on-failureRuns autonomously, but stops and asks when something fails.
neverNever asks. Only available while the bypass policy below allows it.

Sandbox levels

Sandbox levelWhat the agent may write
read-onlyNothing. The agent can inspect but not change.
workspace-writeFiles inside the workspace. The default.
danger-full-accessAnything your user account can write. Only available while the bypass policy allows it.

What Full access means

Full access is the combination of never approvals with the danger-full-access sandbox: an agent that never asks and is not fenced in. It is useful — long refactors in a throwaway worktree do not need a human clicking Approve every minute — and it is exactly the mode an administrator may need to forbid.

The bypass policy gate

That is what the policy gate is for. wingman.agentDev.allowDangerousBypass is an application-level setting that controls whether Full access and permission-bypass launches are available at all. It ships disabled, so Full access is unavailable until an administrator sets it to true for deployments that explicitly permit bypassing approvals. An explicit false in user settings always wins, and workspace-level values are deliberately ignored — a repository you clone cannot re-enable bypass for itself.

settings.json

{
  // Application scope. Workspace values are ignored by design.
  "wingman.agentDev.allowDangerousBypass": false
}

When the policy is off, Wingman does not fail loudly — it degrades safely. A saved never approval policy becomes on-request. A saved danger-full-access sandbox becomes workspace-write. Anyone who tries to select Full access sees: Agent Dev dangerous bypass is disabled by policy. Approval prompts and workspace sandboxing remain active.

Claude Vibe launches

Claude Vibe is the same gate wearing a different button. It is a launch option in the AI tools menu that starts Claude Code in a terminal with --dangerously-skip-permissions — no permission prompts at all — already connected to Wingman MCP. It requires a Wingman sign-in, and its MCP configuration is session-scoped: the connection secrets are written for that terminal session only, cleaned up when it closes, and never persisted into your global Claude configuration. When the bypass policy is off, the launch is blocked with a warning instead of starting.

When bypass is acceptable

Codex administrator requirements

A second, independent layer exists for Codex. Codex administrator requirements (for example /etc/codex/requirements.toml on Linux, or MDM on macOS) can reject the Full access combination no matter what Wingman requests. Wingman treats that fallback as a rejection and tells you Full access is not active, rather than pretending it is. An administrator who wants to permit it must allow both values together — approval_policy = "never" and sandbox_mode = "danger-full-access" — because allowing only one makes Codex fall back to read-only with approvals disabled.

This page is the admin view. The user-facing walkthrough of picking a run mode day to day lives in the Agent Dev tab under Approval policies — send developers there; send this page to whoever owns your fleet policy.