When to Use Danger-full-access, and When Not To

The name itself is doing real, deliberate work — danger-full-access isn't styled as a neutral, maximally-capable option sitting equal among the other two, it's named specifically to make you pause before reaching for it, and treating that naming as an actual, meaningful signal rather than dismissing it as mere dramatic flourish is the entire discipline this page is built around.

What this mode genuinely and completely removes

Under this specific mode, the workspace boundary that otherwise keeps workspace-write scoped tightly to your project directory stops applying entirely — full access means genuinely full access, not "workspace-write with a bit more room." This is the one mode among the three where the sandbox itself stops being the thing constraining what a session can technically reach on your machine.

What still applies even here, without exception

It's worth restating this precisely, because it's genuinely easy to assume otherwise: the protected-paths mechanism covering .git, .agents, and .codex still applies fully under this mode too, exactly as it would under any other, and the destructive-MCP-tool-call approval requirement still applies regardless of approval mode paired with it. Full access removes the workspace boundary specifically; it doesn't remove every other safety mechanism this site covers.

The narrow, legitimate cases this mode actually suits

A task that genuinely needs to read or write meaningfully outside a single project's boundary — coordinating a change across multiple, separately-located projects on your machine, or a task specifically about system configuration rather than a contained project — is the kind of case this mode exists for. These are real, if relatively uncommon, and worth naming explicitly rather than leaving "when is this actually appropriate" as a vague, unanswered question.

The far more common case this mode is wrongly reached for

The more frequent, and more concerning, reason people reach for this mode is impatience with approval prompts under a narrower configuration — treating full access as a way to stop being asked, rather than as a deliberate expansion of what a session can technically touch. This is almost always the wrong fix: the actual friction is usually about approval mode, not sandbox mode, and the two are independent dials for a reason, covered in more depth elsewhere on this site.

Weighing the actual risk honestly before reaching for it

Before enabling this mode for a specific task, it's worth asking plainly what the worst plausible outcome of a mistake would be, given the task genuinely has unrestricted reach beyond the workspace boundary — and whether that worst case is one you're actually prepared to accept, not just one that seems unlikely. A mistake made under ordinary workspace-write is naturally bounded by the workspace itself; a mistake made under this mode isn't bounded in that same reassuring way at all, and that real difference deserves genuine, deliberate consideration every single time, not a reflexive shrug born of habit or impatience.

Scoping the exposure even when this mode is genuinely necessary

If a task does genuinely need this mode, it's worth keeping the exposure as narrow as possible in every other dimension available — a tightly scoped, well-defined task rather than an open-ended one, a shorter session rather than an extended one, closer personal attention to what the session is actually doing rather than stepping away and letting it run unsupervised. None of these substitute for the sandbox boundary itself, but they meaningfully reduce how much could plausibly go wrong while it's absent.

A reasonable default policy

Treat this mode as something you reach for deliberately, for a specific, nameable reason, on a specific, well-scoped task — never as a default you fall into out of general impatience with narrower configurations elsewhere. If you find yourself reaching for it regularly, that's worth treating as a signal to investigate what's actually driving the pattern — usually an approval-mode friction that has a better, narrower fix — rather than simply accepting broad access as a convenient long-term habit.

What to do immediately after a session using this mode finishes

A session that ran under full access is worth a more careful post-session review than one that ran under a narrower boundary — checking what actually changed, not just within the project you were focused on, but more broadly, since the whole point of this mode is that its reach wasn't confined the way a narrower mode's would have been.

Documenting why this mode was used at all, for your own future reference

If a task genuinely, actually warranted full access, it's worth briefly noting exactly why, in your own words, at the time — in a commit message, a task log, wherever makes sense for your workflow — so that a future review of what happened has the reasoning attached, rather than an unexplained gap in an otherwise consistent pattern of narrower sandbox use. This is a small habit, and it matters more the rarer this mode actually is in your normal usage, since a documented rare exception is far easier to audit later than an unexplained one.

The honest test for whether you're using this mode responsibly

If every use of this mode in your own history has a clear, specific, nameable reason attached to it, that's a good sign it's being reserved for genuine cases. If you find yourself unable to articulate why a specific past session needed full access beyond "it was just easier," that's worth treating as evidence the mode has drifted from a deliberate tool into an unexamined habit — exactly the outcome this page is written to help you notice and avoid before it becomes a genuine liability rather than a convenience.