{
"schema_version": 1,
"id": "full-auto",
"description": "Full auto: `approvalMode` is unrestricted, web search is auto-accepted, and the sandbox is disabled. Two of those three change something and one does not, which is worth saying because a posture that restates a default grants nothing while reading as though it grants a great deal. Measured against the 2026.08.25-3e8eec8 bundle, whose own default configuration literal is `{approvalMode: \"allowlist\", autoAcceptWebSearch: false, sandbox: {mode: \"disabled\", networkAccess: \"user_config_with_defaults\"}}`. So `approvalMode` and `autoAcceptWebSearch` both move off their defaults -- the second is a tool the product otherwise asks about every time, declared in the bundle as a boolean defaulting to false -- while `sandbox.mode: \"disabled\"` restates the default and is kept only so the posture survives the product changing it. `sandbox.networkAccess` accepts `user_config_with_defaults`, `user_config_only` and `allow_all`, and is deliberately not set: it governs a sandbox this posture switches off, so writing the most permissive value would be a key that reaches nothing. `attribution` defaults to attributing commits and pull requests to the agent and is left alone, because it sends something outward rather than granting you a tool. Instructions travel as a plugin rule, the way the CLI reads one. This is a setup posture -- keys in this product's own configuration file. It is not an execution profile and it grants no environment: what it changes is what the product asks you and which of its own tools exist, not what anyone is permitted to run. The key measurement behind this posture: the default configuration literal in the 2026.08.25-3e8eec8 bundle, and `autoAcceptWebSearch: z.boolean().default(false)` in its own schema. **And the sandbox has a second input this posture does not write.** Measured 2026-08-30 in the same bundle: the product also reads `join(homedir(), \".cursor\", \"sandbox.json\")` -- a separate policy file carrying `additionalReadwritePaths`, `networkPolicy`, `disableTmpWrite` and `enableSharedBuildCache`, resolved from the process home rather than from `CURSOR_CONFIG_DIR`, and relocatable by an administrator through the resolved permissions' `userSandboxDataFolderName`. This posture writes one key in one file; it does not disable a sandbox that file may configure, and it cannot see that file at all. What is said here is what these three keys do.",
"sources": [
"https://cursor.com/docs/cli/reference/configuration",
"https://cursor.com/docs/reference/sandbox",
"https://cursor.com/docs/reference/plugins"
]
}