What Protected Paths Actually Protect

.git, .agents, and .codex stay protected recursively no matter how permissive the rest of your sandbox configuration is — worth understanding not just as a short list to memorize, but as a specific, deliberate boundary with real, considered reasoning behind exactly which paths it covers and, just as importantly, which paths it deliberately doesn't.

Why these three specifically, and not some broader or narrower list

.git holds your entire version-control history — the one thing that, if corrupted or tampered with, could undermine your ability to trust or recover from any change made during a session, including a change the session itself just made. .agents and .codex hold configuration and state specific to the agentic tooling itself — protecting these prevents a session from modifying the very rules and context governing its own behavior, which would otherwise be a way for a session to quietly alter its own operating constraints mid-task.

Recursive means genuinely, thoroughly recursive, not just the top-level folder

The protection extends to absolutely everything nested inside these directories, at any depth, not merely their immediate top-level contents — a file several levels deep inside .git's internal structure is exactly as protected as the top-level directory itself. This matters because it closes an obvious workaround: if only the top level were protected, nesting a sensitive change deep inside the structure would be trivial to attempt.

The gitdir pointer file detail, worth restating precisely

When .git is a pointer file rather than a literal directory — the case in a git worktree or certain submodule configurations — the protection follows the resolution to the actual underlying git directory, not just the literal pointer file's own bytes. This is a deliberate design choice specifically closing an indirection-based workaround: without it, a worktree could be used to route around the protection simply by virtue of .git not being a "real" directory in that specific working copy.

What these paths don't protect

It's worth being precise about the boundary: these three paths are protected regardless of sandbox mode, but everything else in a workspace-write session remains genuinely writable — ordinary project files, configuration outside these three specific directories, anything else in the workspace. This isn't a broad "protect anything that looks important" mechanism; it's a narrow, specific list, and treating it as broader protection than it actually is would be a mistake with real consequences for anything outside these three paths.

Why the protection can't be disabled, even under danger-full-access

Even the most permissive named sandbox mode doesn't lift this specific protection — it's a structural constraint on the sandbox mechanism itself, not a configurable option within any given mode's settings. This is a deliberate design decision: a mode named for maximum permissiveness still shouldn't be able to compromise the version-history and agent-configuration integrity these paths represent, since doing so would undermine the trustworthiness of every other action a session takes.

What to do if a legitimate task needs to touch one of these paths

For the rare legitimate case — deliberately editing .agents configuration, say — the supported path is making that change yourself, directly, outside of a Codex session's own file-write access, or through whatever explicit mechanism the CLI provides for managing its own configuration deliberately. Treating the protection as absolute for agentic sessions specifically, while retaining your own direct, manual ability to manage this configuration when genuinely needed, is the correct mental model.

Verifying the protection is actually working as expected

If you're setting up a new project structure with an unusual .git configuration — a worktree, a submodule, something less standard — it's worth explicitly testing that the protection behaves as expected in your specific setup, rather than assuming it does purely from this page's general description. A quick attempted write inside one of these paths, expected to be refused, is a fast, cheap way to confirm the protection is actually active for your specific configuration before you're relying on it for something that matters.

Why this protection matters more in an agentic context than a manual one

A human contributor manually editing .git internals directly is already an unusual, deliberate action most developers simply never take in normal work — the protection matters more for an agentic session specifically because an agent operating across many turns, potentially with a broad instruction, has more opportunity to touch something unintended than a human making one deliberate edit at a time ever would. The protection isn't really guarding against a determined bad actor; it's guarding against an agent's own broad, well-intentioned but imprecise interpretation of a task drifting somewhere it shouldn't.

How this compares to relying on .gitignore or file permissions instead

It's worth being clear that this protection is a Codex-specific sandbox mechanism, not a substitute for your operating system's own file permissions or git's own ignore rules — those operate independently and serve different purposes. This protection specifically governs what an agentic session can do; it doesn't replace or interact with the access-control mechanisms your operating system or version-control system already provide for other purposes entirely, and relying on it as a substitute for genuine, separate filesystem-level permissions would be a mistake worth avoiding.

A short summary worth keeping in mind

Three specific paths, protected fully and recursively, regardless of which sandbox mode happens to be active, following pointer-file resolution correctly where relevant, with no configuration option available to disable it even under the single most permissive named mode this CLI offers. That's the entire mechanism from end to end, and its deliberate narrowness — three specific, well-justified paths rather than a broad, vague, hand-wavy notion of "anything that seems sensitive" — is exactly what makes it dependable, predictable, and genuinely easy to reason about correctly every single time.