《Cursor文檔》-運行模式

運行模式決定 Cursor 智能體如何執行工具調用，以及 Cursor 會在何時中斷並請求您批准。

您可以通過它們決定智能體在執行 shell 命令、MCP 工具和 Fetch 調用時擁有多大的自主權。對大多數人來說，最安全且實用的設置是 Auto-review 模式。它會執行已知安全的調用，在可能的情況下將 shell 命令置於沙盒中運行，並讓分類器評審其他操作。

選擇模式¶

在桌面端應用中，前往 設置 > 代理 > 批准與執行。

Auto-review 模式的工作原理¶

Auto-review 模式適用於 shell、MCP 和 Fetch 工具調用。Cursor 會按以下順序檢查每個調用：

如果 shell 命令在沙盒的文件和網絡限制下能夠正常運行，就表示它“可以在沙盒中運行”。需要完整系統訪問權限的命令，例如在工作區外寫入或執行特權操作，無法在沙盒中運行，因此會交由分類器處理。

對於 shell 命令，沙盒機制是運行模式之上的一層機制。它控制受支持的終端命令在哪裏運行，而不決定該模式是否使用 Auto-review 模式分類器。

當分類器阻止某個調用時，Cursor 可以嘗試其他方法。如果智能體認爲儘管分類器作出了這一判斷，該操作仍然合理，Cursor 會向你顯示批准提示。

Auto-review 模式並非安全邊界¶

分類器可能會出錯。它可能允許原本你會阻止的調用，也可能阻止原本你會允許的調用。

Auto-review 分類器要求¶

Auto-review 模式的分類器使用小型 Cursor 託管模型運行。目前爲 Claude 4.5 Haiku 或 GPT-5.4 Mini。

企業版模型訪問控制適用。團隊獲准使用上述任一模型時，即可使用 Auto-review 模式。即使團隊的運行模式中包含 Auto-review 模式，若所有這些模型均被阻止，設置 > agents > 批准與執行中的 Auto-review 模式也會被禁用。成員將改用允許列表。

如果 Auto-review 模式顯示爲灰色，請在團隊設置 → 模型中啓用這些模型，完全退出並重新打開 Cursor，然後再次檢查“批准與執行”。

配置 Auto-review 模式¶

Auto-review 模式無需配置即可正常運行。如果有某些操作您始終希望手動評審，可以用自然語言描述這些操作。

最簡單的設置方式是讓 Cursor 智能體完成。您可以對它說：“我希望每條 AWS CLI 命令都先獲得批准”，它會爲您編輯 permissions.json。

您也可以自行編輯該文件。Auto-review 模式會從以下兩個位置讀取 permissions.json：

如果兩個文件都存在，Cursor 會將其合併。您的個人指令和項目指令都會生效。

團隊也可以在儀表盤中定義全局 Auto-review 模式配置。定義團隊配置後，其優先級更高，Cursor 會忽略用戶級和項目級文件。

兩個本地文件使用相同的 schema。每條指令都是一句自然語言，因此，“我希望每條 AWS CLI 命令都先獲得批准”這樣的請求會直接映射到 block_instructions：

{
  "autoRun": {
    "allow_instructions": [],
    "block_instructions": [
      "Every AWS CLI command should go through approval first.",
      "Every command that modifies Kubernetes resources should go through approval first."
    ]
  }
}

• allow_instructions 用於描述 Auto-review 應優先允許的操作。
• block_instructions 用於描述 Auto-review 應優先阻止的操作，以便智能體選擇其他路徑或請求你批准。

有關策略設計的更多信息，請參閱使用 Auto-review 管理智能體自主性。

沙盒機制¶

沙盒機制讓 Cursor 能夠運行終端命令，而無需授予其對機器的完全訪問權限。沙盒中的命令可以在項目內運行，但不能隨意讀取受保護的文件、寫入獲准路徑之外的位置，或連接任意網絡目標。

如需深入瞭解工程實現，請閱讀爲本地智能體實現安全沙盒。

permissions.json 和 sandbox.json 的作用不同¶

permissions.json 決定 Auto-review 自動執行哪些調用、評審哪些調用。sandbox.json 控制沙盒中的命令可訪問哪些資源，例如網絡域名以及額外的可讀寫路徑。快速入門無需使用這兩個文件。

有些命令需要完全的系統訪問權限，因此會繞過沙盒。命令在沙盒外運行時，Cursor 會提示你並請求批准。

沙箱配置¶

通過 sandbox.json 文件自定義沙箱行爲：

如果兩個文件都存在，Cursor 會合並它們，並以項目級文件爲準。團隊管理員策略和 Cursor 內置的硬性安全規則會疊加生效，因此本地文件無法削弱這些保護措施。

使用 sandbox.json 控制網絡策略、額外的可讀或可寫路徑、臨時目錄寫入和共享構建緩存。完整 schema 請參閱 sandbox.json 參考。

沙箱如何在您的平臺上運行¶

macOS¶

Cursor 通過 sandbox-exec 使用 Seatbelt。生成的沙箱配置文件會限制整個子進程樹的文件訪問、網絡訪問及其他進程行爲。

要求

• Cursor v2.0 或更高版本
• 無需額外設置

Linux¶

Cursor 使用 Landlock 和 seccomp。Landlock 用於限制文件系統訪問。seccomp 會阻止不安全的系統調用。

要求

• 內核 6.2 或更高版本，且支持 Landlock v3 (CONFIG_SECURITY_LANDLOCK=y)
• 已啓用非特權用戶命名空間

如果您的內核不滿足這些要求，Cursor 會改爲在運行命令前請求批准。

AppArmor 設置（僅限遠程環境和 CLI）¶

本地桌面端安裝無需設置。Cursor 桌面端軟件包附帶所需的 AppArmor 配置文件。

某些發行版會通過 AppArmor 限制用戶命名空間，而遠程環境和獨立 CLI 不附帶該配置文件。如果在這些環境中創建沙箱失敗，並出現用戶命名空間權限錯誤，請安裝適用於您的發行版的 AppArmor 軟件包。

Debian / Ubuntu：

curl -fsSL https://downloads.cursor.com/lab/enterprise/cursor-sandbox-apparmor_0.6.0_all.deb -o cursor-sandbox-apparmor.deb
sudo dpkg -i cursor-sandbox-apparmor.deb

RHEL / Fedora：

curl -fsSL https://downloads.cursor.com/lab/enterprise/cursor-sandbox-apparmor-0.6.0-1.noarch.rpm -o cursor-sandbox-apparmor.rpm
sudo rpm -i cursor-sandbox-apparmor.rpm

安裝後，請重新啓動 Cursor 或 CLI 會話，使沙箱生效。

環境變量¶

Cursor 會向每個沙盒化子進程注入環境變量。沙盒內運行的腳本、構建工具和自動化均可使用這些變量。

Linux：沙盒內的 UID 可能與實際用戶 UID 不一致¶

在 Linux 上，沙盒會創建用戶命名空間，並將進程重新映射爲該命名空間中的 UID 0
(root) 。因此，沙盒化命令中的 id -u 和 $UID 會返回 0，
而不是主機用戶 ID。如果腳本或自動化需要主機用戶 ID，例如設置文件所有權或向
Docker 傳遞 --user，請讀取 CURSOR_ORIG_UID 和 CURSOR_ORIG_GID。

Docker 和容器自動化¶

自動化規則和腳本中常見的一種做法是運行需要與主機用戶身份一致的 Docker 容器。由於沙盒會在 Linux 上重新映射 UID，使用 $(id -u) 會得到錯誤的值。請改用 CURSOR_ORIG_* 變量：

docker run --rm \
  --user "${CURSOR_ORIG_UID:-$(id -u)}:${CURSOR_ORIG_GID:-$(id -g)}" \
  -v "$PWD:/work" -w /work \
  my-image build

${CURSOR_ORIG_UID:-$(id -u)} 這一回退機制可確保該命令在沙箱外也能運行，因爲此時變量未設置。

網絡訪問¶

選擇受沙盒限制的終端命令訪問網絡的方式：

查看默認允許的域名¶

*.cloudflarestorage.com
*.docker.com
*.docker.io
*.googleapis.com
*.githubusercontent.com
*.gvt1.com
*.public.blob.vercel-storage.com
*.yarnpkg.com
alpinelinux.org
anaconda.com
apache.org
apt.llvm.org
archive.ubuntu.com
archlinux.org
awscli.amazonaws.com
azure.com
binaries.prisma.sh
bitbucket.org
centos.org
cloudflarestorage.com
cocoapods.org
codeload.github.com
cpan.org
crates.io
debian.org
dl.google.com
docker.com
docker.io
dot.net
dotnet.microsoft.com
eclipse.org
fedoraproject.org
files.pythonhosted.org
fonts.gstatic.com
gcr.io
ghcr.io
github.com
gitlab.com
golang.org
google.com
goproxy.io
gradle.org
haskell.org
hashicorp.com
hex.pm
index.crates.io
java.com
java.net
json-schema.org
json.schemastore.org
k8s.io
launchpad.net
maven.org
mcr.microsoft.com
metacpan.org
microsoft.com
mise.run
nodejs.org
npm.duckdb.org
npmjs.com
npmjs.org
nuget.org
oracle.com
packagecloud.io
packages.microsoft.com
packagist.org
pkg.go.dev
playwright.azureedge.net
ppa.launchpad.net
proxy.golang.org
pub.dev
public.blob.vercel-storage.com
public.ecr.aws
pypa.io
pypi.org
pypi.python.org
pythonhosted.org
quay.io
registry.npmjs.org
registry.yarnpkg.com
repo.maven.apache.org
ruby-lang.org
rubygems.org
rubyonrails.org
rustup.rs
rvm.io
security.ubuntu.com
sh.rustup.rs
sourceforge.net
spring.io
static.crates.io
static.rust-lang.org
sum.golang.org
swift.org
ubuntu.com
visualstudio.com
yarnpkg.com
ziglang.org

其他保護機制¶

運行模式和沙盒機制並非僅有的安全控制措施。即使某個模式本應自動運行，以下保護機制仍可能要求批准：

團隊控制¶

管理員可以設置用戶可用的模式，還可配置終端命令的沙盒網絡規則等。所有這些設置均可在網頁端儀表盤中管理。

團隊設置優先於個人和項目配置。需要爲所有成員設定統一的基準時，請使用這些設置。如果您爲團隊啓用 Auto-review 模式，請確保在模型訪問控制中允許分類器所需的模型之一。

更新日誌¶

Cloud Agents 不使用運行模式¶

運行模式適用於本地智能體。Cloud Agents 在各自的專用機器上運行，因此智能體不會要求你批准操作。