A Non-Version-Controlled Folder Starts Read-Only

The mistake

Pointing Codex at a fresh scratch directory, a newly unzipped archive, or a project you haven't run git init in yet, then being confused when it can't edit anything — even though you didn't pass any flag that should have put it in a read-only sandbox.

Why this happens

Codex's default trust posture isn't the same for every folder. A version-controlled directory starts in the ordinary Auto posture — read, edit and run inside the workspace, with approval needed to step outside it. A directory with no version control starts read-only instead, until you explicitly trust it. It's a sensible default once you know it exists — an untracked directory has no history to diff against, so there's less signal available about what a change actually did — but nothing about a plain edit attempt announces why it was refused, and the folder just behaves as if it's broken.

Why it matters

This is easy to hit at exactly the moment it's most disruptive: starting something new. A quick scratch project, a downloaded example repo you haven't initialized yet, a directory you're about to git init but haven't gotten to — all of these look, to a new user, like ordinary writable folders that Codex should just work in. Spending time debugging a permissions problem that isn't really about permissions at all, on a brand-new project, is a bad first impression of the tool for exactly the group of people least equipped to recognize what's happening.

The fix

If version control is appropriate for the project — and for most real work, it is — run git init before you start, and the directory picks up the normal Auto posture. If you deliberately want to work in a directory without version control, explicitly trust it or switch to a sandbox mode that grants write access outright, rather than treating the read-only refusal as a bug to work around.

It's also worth noticing what this default gets right, once it's no longer surprising: pointing an agentic tool at an arbitrary, unfamiliar directory and having it default to read-only is a sane starting posture for exactly the same reason it's a mildly annoying one to a developer who already knows the folder is safe. The cost of the default falls entirely on the person who understands the context; the benefit falls on everyone who might otherwise have pointed Codex somewhere without thinking about it first.

See also

Trusting a new project directory covers the explicit trust step in more depth, including what it does and doesn't grant beyond the read-only default.