Your First Time with Codex: Hold These 5 Safety Boundaries First

What's different about Codex isn't that its answers sound more like a programmer

An ordinary chat window gives you a suggestion; Codex, once it has permission, can read files, edit code, run commands, access the network or call external tools directly. The value comes from that step — and so does the risk.

When the task boundary isn't written clearly, the problem isn't just "a bad answer." It can open the wrong directory, edit a file out of scope, or mistake "done locally" for "already deployed."

OpenAI's public safety notes separate sandbox from approvals: the sandbox constrains the technical scope of execution, while approvals decide which out-of-bounds actions need explicit consent. Those two layers help control execution, but they won't define the task goal for you.

The first time I use Codex, I care more about whether it can stop, explain itself and roll back inside a very small scope — not how much code it changes in one go.

Step 1: treat only the current project as the workspace

The easiest mistake is handing the agent your whole home directory for convenience. Then project code, personal documents, downloads, browser data and key directories can all enter its visible range.

A first task should satisfy:

• The workspace is one specific project directory.
• There are no real production keys in the project.
• The sample data is disposable.
• The edit scope can be read in a few glances.
• Even if the task fails, it won't affect other projects.

If it's just practice, make a minimal HTML page or use a throwaway sample repo. Watch which files Codex reads, which commands it proposes, and how it describes its changes — before you move into a real project.

Step 2: break "what it can do" into a permission matrix

Permissions aren't just allow and deny. You can layer them by risk:

Read-only: view files, search code, explain structure.

Workspace write: edit agreed-on files inside the current project.

Run commands: run builds, tests or local scripts.

Network access: download dependencies, check docs, call APIs.

System changes: install global software, change the shell, services or permissions.

External actions: commit, push, deploy, send messages, publish or spend money.

A task usually only needs the first two or three layers. Don't open all permissions at the start just because it might deploy eventually.

OpenAI's safety notes stress that the network should be bounded too: a familiar, low-risk target and open-ended outbound access aren't the same thing. For a beginner, the simplest move is to say in the task itself "don't go online," "don't install dependencies," or "only the official docs are allowed."

Step 3: handle secrets and production data separately

Don't paste API keys, cookies, OAuth tokens, private keys or passwords into a prompt, source code or chat screenshots.

If the task genuinely has to call a service, prefer:

• A test account.
• A temporary or low-privilege key.
• Redacted data.
• An environment variable only the current project can read.
• A credential channel that won't land in logs.

Also check whether the code itself prints environment variables, headers or full error objects. The agent isn't actively "stealing keys," but debug output can still write one into a file.

If real production credentials aren't required for the task, keep them out of the workspace entirely.

Step 4: dangerous commands must carry scope and consequence

Delete, overwrite, bulk-replace, database migrations and Git history operations can all be irreversible.

A reliable execution request states at least:

• What the command will change.
• Which files or data it affects.
• Why the current task needs it.
• Whether there's a smaller-scope alternative.
• How to roll back.
• What to look at afterward to judge the result.

Above all, don't read "fix my project" as license to clean up every uncommitted file. Changes in the workspace might come from you, another tool, or a parallel task.

When an unexpected change appears, the right move is to stop and confirm the source — not to use a destructive command to restore the whole directory to some point in history.

Step 5: external actions are always authorized separately

Local code running doesn't mean it can commit to Git.

Tests passing doesn't mean it can push.

A preview page looking fine doesn't mean it can deploy to production.

An API returning success doesn't mean the result appeared on the platform.

Splitting these apart has two benefits: you know exactly when risk crosses from local into the outside world, and each step can be accepted with its own matching evidence.

One authorization covers only the current, specific action. Allowing a deploy last time doesn't mean later changes go live automatically.

How to write the first task

A runnable task has five parts.

Goal

What the user should ultimately see — not just "optimize it a bit."

Scope

Which files may be read and edited.

Boundaries

What it must not install, go online for, reconfigure, publish, or touch.

Acceptance

Judge success with a page, a command, a test or an output file.

Stop condition

What to stop and report when it hits a missing file, a conflict, insufficient permission or an unexpected change.

For example:

Goal:
No horizontal scroll on the sample homepage at 390px width.

Scope:
Read only index.html and styles.css; only styles.css may be edited.

Boundaries:
Don't install dependencies, don't access the network, don't run Git or deploy.

Acceptance:
Open the page with the existing preview method and confirm the body, images and buttons are all inside the viewport.

Stop condition:
If the problem comes from another file, name the file first — don't widen the edit scope.

That gets a controllable result more reliably than "help me make my site look better."

A safe flow for the first collaboration

Before running

1. Confirm the current working directory.
2. Back up irreplaceable data.
3. Check for your own unsaved changes.
4. Make clear which files may be touched.
5. Move out unnecessary credentials.
6. Write down the forbidden external actions.

While running

1. Have Codex say what it plans to read first.
2. Keep edits within the agreed scope.
3. Explain the consequence of high-risk actions first.
4. Stop immediately on an unexpected file change.
5. When the same approach fails repeatedly, narrow the problem — don't widen permissions and hope.

After running

1. Read the actual changes, not just the summary.
2. Accept it with the method that maps to the goal.
3. Check that no new keys, temp files or internal addresses were added.
4. Separate "done locally" from "done externally."
5. Decide whether a next commit or deploy is needed.

How to understand sandbox and approvals

The sandbox is a technical boundary — for example, allow writing the current project, protect other paths, limit the network.

Approvals are a decision boundary — for example, when an action exceeds the default scope, you have to allow it explicitly.

Both matter, but they don't replace backups, code review or goal definition. A command inside the sandbox can still delete an important file in the current project; an approved network request can still hand data that shouldn't be sent to an external service.

Don't read "the system allowed it" as "it's correct for the business."

When Codex claims it's done, ask which layer the evidence belongs to

Different evidence only proves different facts:

• A file exists: proves a local write happened.
• The build passes: proves the current build conditions are met.
• Tests pass: proves the behavior those tests cover passes.
• A page screenshot: proves the result seen at one viewport.
• A Git commit: proves the change entered local history.
• A push receipt: proves the remote repo received the commit.
• A production-URL read-back: proves the public environment returns a result.

None of these automatically stands in for everything after it. The most common mix-up is calling "local build succeeded" the same as "it's live."

When something goes wrong, don't rush a one-click rollback

If Codex edited a file out of scope:

1. Stop executing.
2. Record which files changed.
3. Separate this round's changes from pre-existing uncommitted ones.
4. Handle only the part you can confirm belongs to this round.
5. Don't use a destructive command that overwrites the whole workspace.

If it fails the same way twice, change the verification path or narrow the task. Failing twice doesn't mean it needs higher permissions.

If it says done but has no evidence, the status is unconfirmed. Ask it to point to the file, the command result or the external read-back; when you can't get that, don't fill in the conclusion for it.

For a first task, this is enough

Not how much code Codex wrote, but:

• Changes only happened within the agreed scope.
• You can explain why it changed things this way.
• The acceptance evidence maps to the user goal.
• No credentials or production data were exposed.
• No unauthorized Git, deploy, publish or billing actions.
• You know how to stop when something goes wrong.

Run one controlled collaboration in a small, disposable project first. Once you can point to what it read, what it changed, how you accepted it, and where it didn't overstep, carry the same rules into a real repo.