Skip to main content

Documentation Index

Fetch the complete documentation index at: https://cli.devin.ai/docs/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

Team-wide settings allow enterprise admins to control Devin CLI usage across their organization.
  • Devin Enterprise admins can manage these settings in the customer-facing Devin dashboard under Settings → Enterprise → Windsurf (app.devin.ai/org/{orgName}/settings/windsurf). This is self-service for admins with access to enterprise settings.
  • Windsurf Enterprise admins can manage these settings in the Windsurf dashboard at https://windsurf.com/team/cli-settings.
Only the Devin CLI-specific settings on these pages apply to Devin CLI. General Windsurf Team Settings apply to Windsurf and do not necessarily apply to Devin CLI unless also listed on the Devin CLI settings page.

​
Available Settings

​
Models

Control which models your users can access through Devin CLI. You can:
  • Whitelist specific models — Restrict users to a curated list of approved models
  • Allow all models — Give users access to all available models
Click Configure to manage model access for each category.

​
Default model

You can also pin a team-wide default model that Devin CLI will use for new sessions. This is the same setting Windsurf uses for its default model, so configuring it once applies to both surfaces.
  • If no team default is set, Devin CLI uses its built-in default model.
  • If the pinned default is not present in the allowed models list above, Devin CLI falls back to the built-in default — the allowlist always takes precedence.
  • Individual users can still switch models during a session; this setting only controls the starting model for new sessions.
Enterprise admins can configure the default model from the Windsurf Team Settings page, the Devin CLI Settings page, or the customer-facing Devin Enterprise settings page at app.devin.ai/org/{orgName}/settings/windsurf. Allow the Devin CLI agent to perform web searches on the open Internet. This does not affect the agent’s ability to read specific URLs, which is performed locally on the user’s machine. This tool is disabled by default for enterprise teams.

​
MCP Servers

Control whether your users can use MCP (Model Context Protocol) tools.
  • Toggle on/off — Enable or disable MCP server usage entirely
  • Whitelisted MCP Servers — Specify which MCP servers users are allowed to connect to. If no servers are added, all servers are whitelisted by default. Click Add Server to restrict access to specific servers.

​
Terminal Permissions

Configure team-enforced permission rules for Devin CLI usage. These rules have the highest precedence and cannot be overridden by individual users’ local or project configurations. Click Configure to open the permissions editor. The configuration requires a JSON object with three fields: 
{
  "deny": [
    "exec"
  ],
  "ask": [],
  "allow": [
    "Read(~/my-repository/**)"
  ],
}
  • deny — Actions that are blocked entirely (takes highest priority)
  • ask — Actions that always prompt the user for approval
  • allow — Actions that are automatically approved without prompting
Permissions can be scope-based or tool-based:
TypeFormatExample
File readRead(/path)Read(~/sensitive/**)
File writeWrite(/path)Write(.env*)
Command executionExec(cmd)Exec(rm), Exec(sudo)
HTTP fetchFetch(url)Fetch(https://internal.api/*)
Tool-basedTool nameread, edit, exec
Use team-enforced deny rules to prevent actions across your entire organization, such as blocking access to sensitive directories or dangerous commands like rm -rf or sudo.
For detailed information on permission syntax, glob patterns, and configuration examples, see the Permissions documentation.

​
Sandbox Enforcement

Control sandbox behavior for your organization. These settings enforce OS-level isolation on all CLI sessions, restricting file system access and network traffic.

​
Sandbox Enforcement Mode

Set the enforcement level for the --sandbox flag across your organization:
  • Optional (default) — Users choose whether to pass --sandbox. No enforcement.
  • Required — The --sandbox flag is forced on for all users, even if they don’t pass it on the command line. All CLI sessions run with OS-level file system sandboxing that enforces Read/Write permission scopes.
A future Strict mode may lock down sandbox configuration entirely, preventing users from modifying sandbox settings. When sandbox is active:
  • Writable paths are derived from granted Write(...) permission scopes plus the workspace directory
  • Readable paths are derived from granted Read(...) scopes (platform defaults like /usr/bin are always readable)
  • Scopes granted mid-session dynamically expand the sandbox for subsequent commands
If sandbox resolution fails (e.g., the sandboxing tools are unavailable on the user’s platform), the CLI will refuse to start rather than running unsandboxed. This fail-closed behavior applies whether sandbox was enabled via this team setting or by the user passing --sandbox directly, ensuring the security intent is never silently bypassed.When enterprise-enforced, users will see an error directing them to contact their team administrator. When user-initiated, the error suggests running without --sandbox to proceed without OS-level isolation.Common causes of sandbox resolution failure:
  • Windows: OS-level sandboxing is not currently supported on Windows. Sessions on Windows will hard-fail when --sandbox is passed or when sandbox enforcement is Required, including when the CLI runs as an ACP server inside an IDE (e.g., Windsurf).
  • Linux: Sandboxing requires bubblewrap (bwrap) and socat to be installed. Sessions hard-fail with installation instructions when these are missing.
  • Permission scope errors: Invalid paths in permission scopes that can’t be resolved.
Ensure all target machines are provisioned before setting sandbox enforcement mode to Required across your organization. If any users are on Windows, they will be unable to run the CLI until OS-level sandboxing is supported on Windows or the policy is relaxed to Optional.

​
Domain Filtering

Configure organization-wide domain allowlists and denylists for sandbox network filtering.
  • Domain allowlist — When set, only the domains in this list are reachable through the sandbox network proxy. This list is authoritative: it completely replaces any user-configured allowed_domains in their local sandbox config. Users cannot add additional domains to bypass admin restrictions.
  • Domain denylist — Domains that are always blocked. Enterprise denied domains are additive: they are merged with the user’s local denied_domains, making the combined list more restrictive.
See the sandbox config reference for domain pattern syntax (e.g., *.example.com, **.example.com). How enterprise and user domain lists interact:
ScenarioEnterprise configUser configEffective result
Admin sets allowlistallowed_domains: ["github.com"]allowed_domains: ["npmjs.org"]Only github.com is allowed (enterprise replaces user list)
Admin sets denylistdenied_domains: ["evil.com"]denied_domains: ["risky.io"]Both evil.com and risky.io are blocked (merged)
No admin allowlistallowed_domains: []allowed_domains: ["github.com"]User’s allowlist is used
Because the user’s local denied_domains are preserved and merged additively, a user could deny a domain that appears in the enterprise allowlist. This is intentional: the combined effect is always more restrictive, never less. If this causes access issues, the user should remove the conflicting entry from their local config.
Combine sandbox enforcement with team permission deny rules (e.g., Write(/etc)) to prevent agents from modifying sensitive directories at both the permission and OS level. Permission deny rules prevent the agent from even attempting the action, while the sandbox provides a second layer of OS-level enforcement.

​
Show “Install Devin CLI” in the Windsurf Command Palette

Devin CLI is bundled with Windsurf (starting with version 1.9577.24) but requires explicit activation by an admin. Toggle this setting on to allow your users to install Devin CLI directly from the Windsurf Command Palette. Once enabled, users can open the Command Palette (Cmd+Shift+P on macOS or Ctrl+Shift+P on Windows/Linux) and run Install Devin CLI to add the devin binary to their PATH.
This setting is available on Windsurf Enterprise and Devin Enterprise plans and is off by default.

​
Further Reading

To understand how to configure Devin CLI further, see the Configuration documentation.