Step 3: Set Up the Codex Sandbox

When you log into Codex for the first time, you'll see a "Set Up Sandbox" prompt almost immediately. Most business owners click through it without thinking. Some skip it entirely and jump straight to connecting plugins or issuing tasks.

Both approaches are mistakes.

The sandbox is not a technicality. It is the container Codex lives and operates in — the designated environment your agent calls home on your machine. Every task Codex runs, every file it touches, every automation it builds executes inside this container. What you configure here sets the terms for everything that follows.

This post covers exactly what the sandbox is, how to set it up correctly, and the most common mistakes business owners make in the first fifteen minutes that quietly break everything they try to build afterward.

Watch me explain this live — I walked through this in real time during the setup session.

For the complete framework, read the full guide.

What the Sandbox Actually Is

Think of the sandbox like a designated workstation inside your computer — a zone where Codex operates, stores its working files, runs its commands, and maintains its environment. It is isolated from the rest of your machine in a meaningful way, but it connects outward to your files, your cloud storage, and your plugins.

The analogy I use: it is a literal sandbox on a playground. Everything Codex does happens in that sandbox. The edges matter. What you put inside matters. And what permissions you grant within that space determine whether Codex can actually move freely or is constantly hitting invisible walls.

This is the foundational layer. Not the most exciting step in the setup process, but the load-bearing one. Skip it or configure it wrong and every layer above it — plugins, automations, skills, the Agent Home Base — becomes less stable.

The Two Things You Must Decide Before You Click Anything

Before you configure the sandbox itself, two decisions need to be made. Most business owners make neither consciously, which is why the setup causes problems later.

Decision 1: Where will Codex's work live?

The sandbox defaults to local storage — meaning everything Codex produces lives on your machine. That is a risk. If your computer is lost, damaged, or replaced, the work is gone. You need to decide upfront whether your cloud backup is Google Drive, Dropbox, or GitHub, and configure that routing before Codex starts producing output.

From my own setup: I migrated away from iCloud as my primary option because Codex flagged it directly — the root structure was too large and too mixed to be reliably accessible for agent retrieval. Google Drive became my primary cloud storage. If your business runs primarily on Dropbox, that can work, but the decision needs to be made deliberately, not after the fact.

Learn about cloud storage strategy for Codex — this decision deserves its own post, and I've written it.

Decision 2: What level of access will you grant?

This is the bigger one. The sandbox setup is where permissions are first established. If you leave Codex on "failure," "untrusted," or "read-only" at this stage, you will spend the next several hours approving micro-decisions manually and wondering why your agent feels slow and broken.

It is not broken. It is cautious. And you made it that way.

Learn how to configure permissions correctly — full access is non-negotiable for agentic operation, and I explain exactly why there.

Setting Up the Sandbox: What to Configure and Why

Here is the exact setup sequence that matters:

The Sleep setting is one most business owners miss entirely because it sounds minor. It is not. Codex can run goals that last 24 to 36 hours or longer. If your computer goes to sleep mid-task, Codex stops. The task doesn't pause cleanly. It breaks. Toggle Prevent Sleep on before you run anything.

The Permissions Problem — and Why It Shows Up Here

When you're inside the sandbox settings, you'll see permission options. The temptation is to start restrictively — "I'll give it full access later, once I understand it better."

The problem: restricted permissions don't protect you. They stop Codex at every micro-step and require manual approval for file reads, folder access, browser navigation, and command execution. What you've built at that point isn't an agent. It is a slower version of doing the work yourself, with more steps.

If you can't change the permission setting directly in the UI — which happens — the fix is straightforward: copy the error message, open a Codex chat, and use the permissions setup prompt from the Skills Dashboard to have Codex resolve it from your machine directly.

On Mac specifically: when you toggle on Computer Use and Browser Use, macOS may surface accessibility or screen recording permission pop-ups. Read every one of them before approving. If the wording doesn't match what Codex told you it would do, do not approve it. Ask Codex to describe the pop-up first. That's not paranoia — it's the right habit.

The Most Common Mistake in the First Fifteen Minutes

The mistake I see most often isn't skipping the sandbox setup entirely. It's completing it too fast and assuming the defaults are fine.

They are not.

The default configuration leaves business owners with:

• Local-only storage (no cloud backup)
• Restricted permissions
• Sleep prevention off
• Speed left on Fast (which burns credits)

None of these are catastrophic in isolation. Combined, they produce a system that runs slowly, stops when your computer sleeps, burns through your monthly credits in days, and loses work if anything happens to your machine.

Each of these defaults requires a deliberate override. The setup screen is where you make those overrides — not after you've already run a 30-hour goal and lost the output.

What the Sandbox Enables Once It's Done

Once the sandbox is properly configured, it becomes invisible in the best way. You stop thinking about it. Codex simply operates.

From here you can:

• Connect plugins and have Codex actually retrieve data through them
• Set up named environments for specific projects so work stays separated
• Run onboarding skills without hitting permission blocks at every step
• Issue long-duration goals without worrying about sleep interrupting them

The sandbox is not the interesting part of working with Codex. But it is the part that determines whether all the interesting parts work.

Before You Move On

Run through this checklist before you proceed to any other setup step:

• [ ] Sandbox initialized — not dismissed or skipped
• [ ] Cloud storage routing decided and configured (Google Drive, Dropbox, or GitHub)
• [ ] Full access granted in sandbox permissions
• [ ] Prevent Sleep While Running toggled on
• [ ] Speed set to Standard
• [ ] Computer Use toggled on
• [ ] Browser Use (Google Chrome) toggled on
• [ ] Suggested Prompts toggled off
• [ ] Mac users: macOS accessibility pop-ups reviewed and approved deliberately

If any of these are unchecked, fix them before running any skills or issuing any tasks. The onboarding skills — including the permissions audit — should be your first actions after this list is complete.

The Foundation Phase is not glamorous. But everything you build on top of it depends on what you do here.

-- This post is paired with LinkedIn post: linkedin-posts/post-04.md

— Shanee