Install WordPress on this domain, switch on LiteSpeed Cache and then make
a backup of the account.
That is one request, but it touches three different places on the server: your website folder, a plugin's settings, and a backup folder outside your website. With Codex connected, this is exactly the moment the word sandbox starts to matter. This article explains what Codex may and may not do, without you having to configure anything.
What a sandbox is
Codex does not run loose on the server. It works inside a fence that is set in advance: reading is broad, writing is only allowed in places that are explicitly permitted. That setting is called workspace-write. The working folder is your web root, the folder holding the files of the website you are working on.
This is not something we switch on or off per customer. It is the default, and it is stricter than the permissions your own account has. Your account may write anywhere in your home folder, for instance; Codex inside the sandbox may not, unless the folder is on the list.
What falls inside the fence
Three kinds of place:
| Place | Why |
|---|---|
| The web root of the website you are working on | that is where the work happens |
| The folder above your web root | log files and connected repositories live there |
| A handful of working folders in your home | the hosting tools write their temporary files there |
That last category is the reason this article exists. When you ask for a database, a backup or a WordPress install, Codex does not start a database itself; it calls our tooling. That tooling writes into hidden folders in your home: a queue for databases and git links, the backup tool's folder, the cache of the WordPress command line, the notes about your website, and /tmp for work that may be thrown away afterwards.
If those folders were not on the list, exactly that kind of request would fail. Not with a clear message, but with a permissions error halfway through a task that was going fine until then. So they are on the list now.
What falls outside
Everything that is not yours. Other accounts, the settings of the server itself, the folders of websites on your account other than the one you are working on. On shared web hosting the shielding of your account comes on top of that: Codex works as your user, within the limits of your plan, and does not see the rest of the server. See Shielded account or admin rights for what that means per task.
On a Claude Server the picture is different: there the assistant works with admin rights and can touch accounts, DNS and server settings. The sandbox still applies to the working folder, but the permissions around it are wider.
Codex is allowed on the internet. That is needed to fetch WordPress, plugins and packages.
What you notice when something is blocked
Usually nothing, because the folders that are needed are on the list. When a request does hit the fence, you see it in two ways:
- Codex reports that a helper tool is stuck on a protected folder. That is the sandbox, not broken tooling.
- Codex then does it itself, by hand. That is how it works: in auto mode it keeps going with an assumption rather than stopping to ask.
We saw that second point in a test of our own on an empty website. Our WordPress install command got stuck on three admin folders. Codex reported it and then installed WordPress manually: over four hundred files, placed by hand. The end result was a working site, just along a different route than intended. That is the pattern to know: Codex does not stop, it picks a detour.
Common mistakes
Thinking the sandbox protects you against a wrong change in your website. It does not. Inside your web root Codex may do anything, including overwriting a file you would rather have kept. The protection is outside it. For inside, use the undo on a request, and for bigger rebuilds a backup first.
Asking for something outside your account. "Raise the PHP limit on the server" or "look in the server mail log" is not possible on shared hosting, and that is not a fault. Ask us, or see whether a Claude Server fits what you want to do.
Reading the protected folder message as an error in your site. It is a boundary, not a defect. Read what Codex did next, because that is what actually happened.
Assuming Codex asks permission along the way. It does not: it carries out the request and then shows the changes as a card. If you want to decide per change up front, use Claude Code. See Claude Code or Codex.
Starting two requests at once on the same account. The tooling in those working folders assumes one task is running. Let a request finish before you start the next.
Not connected yet? The four steps are in Connect Codex to your DirectAdmin account, and what Codex can do on your plan is at Codex in your hosting.