Local AI coding agents are powerful because they sit close to the work.
They can read the repository.
They can edit files.
They can run tests.
They can call tools.
They can sometimes interact with apps and connectors.
That is also why the security model matters.
The safest question is not, “Do I trust the model?”
The safer question is, “What can this agent actually do without asking me?”
Codex has a useful answer to that question.
Its security controls are built around sandboxing and approvals.
Those two ideas sound similar.
They are not the same thing.
The sandbox defines what Codex can technically access.
The approval policy defines when Codex must stop and ask.
When those two layers are configured well, local AI coding feels fast without feeling reckless.
When they are configured loosely, one mistaken command can have a wider blast radius than the user intended.
This guide turns the official Codex model into a practical checklist.
It is written for developers, team leads, and AI-ops operators who want local agents to be useful every day.
It is not a substitute for your organization’s security policy.
Use it as a practical review map.
The Practical Answer
For daily local development, start with three defaults.
Use a workspace-scoped sandbox.
Keep network access off unless the task requires it.
Require approval for actions outside the trusted workspace.
That gives the agent enough room to edit and test code.
It also keeps the agent from quietly writing somewhere unrelated.
It keeps package downloads, network calls, and external side effects visible.
In Codex terms, the key distinction is simple.
Sandbox mode is capability.
Approval policy is interruption.
The sandbox answers, “Where can this command write?”
The approval policy answers, “When does the user get a prompt?”
You want both answers to be deliberate.
Sandbox Mode vs Approval Policy
OpenAI’s Codex documentation describes two security layers.
The first layer is sandbox mode.
This controls what Codex can do technically when it runs model-generated commands.
Examples include where it can write.
Examples include whether it can reach the network.
Examples include whether it is limited to the active workspace.
The second layer is approval policy.
This controls when Codex has to ask before it acts.
Examples include leaving the sandbox.
Examples include using the network.
Examples include running commands outside a trusted set.
The difference matters.
A sandbox can block access even if the model wants to do something.
An approval policy can pause for human review before the action proceeds.
Good setups use both.
Bad setups rely on vibes.
Vibes are not a security control.
Very poetic.
Still not a control.
A Good Local Default
For local CLI or IDE work, Codex defaults are intentionally conservative.
The official docs describe defaults with no network access.
They also describe write permissions limited to the active workspace.
That is a good daily base.
Most coding tasks do not need full filesystem access.
Most coding tasks do not need the network after dependencies are installed.
Most coding tasks can be completed inside a repository.
That is exactly the shape a workspace sandbox is designed for.
The agent can inspect files.
The agent can patch source.
The agent can run local tests.
The agent can report what changed.
If it needs to write elsewhere, it should ask.
If it needs network access, it should ask.
If it wants to perform a destructive external tool action, it should ask.
That is not friction for its own sake.
That is the point where the operator regains context.
The Checklist
Use this as a preflight before giving an agent more autonomy.
Confirm the working directory.
Confirm the repository is the intended repository.
Confirm the sandbox mode.
Confirm the writable roots.
Confirm whether network access is enabled.
Confirm the approval policy.
Confirm whether app or connector tools have side effects.
Confirm whether destructive tools are annotated and require approval.
Confirm whether secrets are readable in the current environment.
Confirm whether generated logs can expose sensitive data.
Confirm whether package installation is allowed.
Confirm whether the task can be done offline.
Confirm whether the agent should stage, commit, or push.
Confirm whether the agent is allowed to open GUI apps.
Confirm whether the agent should stop before deployment.
That checklist sounds basic.
Basic is good.
Basic is how expensive incidents get bored and leave.
Config Keys That Matter
The Codex configuration reference lists the security-sensitive keys an operator should know.
The common ones are approval_policy, sandbox_mode, and sandbox_workspace_write.*.
The sandbox_mode setting can be read-only, workspace-write, or danger-full-access.
The workspace-write posture is the usual daily-development sweet spot.
It lets Codex work in the project.
It does not casually grant the whole machine.
The sandbox_workspace_write.writable_roots key can add extra writable directories.
Use that carefully.
Each extra root is a larger write surface.
The sandbox_workspace_write.network_access key controls outbound network access in workspace-write mode.
Keep it disabled by default when the project can be tested locally.
Turn it on only for tasks that need it.
Examples include dependency installation, API checks, or live documentation fetches.
The tools.web_search setting controls web search availability.
That is useful for current documentation.
It is also a data-flow decision.
An operator should know when a task is using live web context.
A Simple config.toml Shape
Here is a conceptual local profile.
Do not copy it blindly.
Use it as a thinking template.
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = false
writable_roots = []
This says three things.
The agent can work in the workspace.
The agent cannot use network access by default.
The agent can ask for approval when it needs to go beyond that boundary.
That is usually a healthy starting point.
For a locked-down review session, use read-only mode.
For a trusted automation environment, you may choose a different setup.
But the decision should be written down.
Security that lives only in someone’s memory is a scheduled surprise.
When Read-Only Is the Right Mode
Use read-only mode when the task is analysis.
Use it for code review.
Use it for architecture exploration.
Use it for incident triage.
Use it for unfamiliar repositories.
Use it when the user wants a plan before edits.
Use it when the branch is sensitive.
Use it when the agent should not run tests that create files.
Read-only mode is not a punishment.
It is a thinking mode.
The agent can still be useful.
It can map the codebase.
It can identify likely files.
It can explain risk.
It can propose changes.
Then the operator can switch modes when the work is ready.
When Workspace-Write Is the Right Mode
Use workspace-write mode when the task is normal implementation.
Bug fixes fit here.
Refactors fit here.
Documentation edits fit here.
Test updates fit here.
Local build checks fit here.
The important part is scope.
The project directory is the work zone.
The agent should not need random home-directory writes.
The agent should not need secret files.
The agent should not need unrelated repositories.
If it does, pause and ask why.
Sometimes there is a good reason.
Most of the time there is a simpler route.
Be Careful With Full Access
Full access modes exist for a reason.
They can be useful in controlled environments.
They can be useful for dedicated sandboxes.
They can be useful when a human operator understands the blast radius.
They are not a casual productivity toggle.
The problem is not that the model is trying to be malicious.
The problem is that commands are powerful.
Wrong path.
Wrong environment variable.
Wrong script.
Wrong deploy target.
Wrong credential scope.
That is enough.
Full access should be rare for local daily work.
If a team uses it, the team should document why.
Network Access Is a Separate Decision
Network access deserves its own line in the checklist.
Many tasks do not need it.
Running unit tests usually does not need it.
Editing a component usually does not need it.
Updating a README usually does not need it.
But some tasks do need it.
Installing dependencies needs it.
Checking current API docs may need it.
Publishing a package needs it.
Calling a staging service needs it.
The risk is not only exfiltration.
The risk is also irreproducibility.
A test that depends on a live service can pass today and fail tomorrow.
A dependency install can mutate lockfiles.
A script can talk to the wrong account.
So network access should be intentional.
Off by default is a strong habit.
On by approval is a practical compromise.
App and MCP Tools Need Review Too
Security is not only shell commands.
Codex can work with apps and connectors.
Some tools are read-only.
Some tools have side effects.
Some tools can create, delete, send, publish, or modify external state.
The official docs note that Codex can elicit approval for app tool calls that advertise side effects.
Destructive app or MCP tool calls require approval when the tool advertises a destructive annotation.
That is important.
Operators should not treat connector tools as harmless just because they are not shell commands.
Sending a message is a side effect.
Publishing a post is a side effect.
Changing a ticket is a side effect.
Deleting a cloud object is definitely a side effect.
Make tool annotations part of the trust model.
A Practical Risk Table
| Action | Typical risk | Safer default |
|---|---|---|
| Read repository files | Low to medium, depending on secrets | Allow inside trusted workspace |
| Edit project files | Medium | Allow in workspace-write mode |
| Write outside workspace | Medium to high | Require approval |
| Use network | Medium to high | Off by default, approve when needed |
| Install dependencies | Medium | Approve and inspect lockfile changes |
| Run destructive shell commands | High | Require explicit approval |
| Use publishing tools | High | Require explicit review before publish |
| Access secrets | High | Keep out of agent-readable paths when possible |
This table is intentionally boring.
Boring tables are underrated.
They make the future incident report shorter.
The Repository Boundary
The active workspace should be the agent’s main operating room.
That boundary is easy to explain.
It is also easy to audit.
Everything changed should appear in git status.
Everything reviewed should be in the repository or a known writable root.
Everything outside that boundary should feel unusual.
This is where writable roots matter.
Adding a writable root can be reasonable.
A monorepo may need a sibling package.
A build may need a local output directory.
A documentation generator may need a configured export folder.
But each extra writable root should have a reason.
Do not add broad roots because one command complained.
Fix the command or approve the one-off action.
Secrets and Environment Variables
Local development often has secrets nearby.
API keys.
Tokens.
Cloud credentials.
Database URLs.
Cookie files.
SSH configs.
The safest pattern is to avoid placing secrets where the agent needs to read.
If a command requires secrets, ask whether the task really needs that command.
For many code changes, the answer is no.
For deployment, the answer may be yes.
That is a different risk class.
Treat it differently.
Do not mix ordinary editing and production credential access in the same mental bucket.
Tests Are Not Automatically Harmless
Running tests feels safe.
Usually it is.
But tests can write files.
Tests can call services.
Tests can mutate local databases.
Tests can start servers.
Tests can consume paid API quota.
Tests can read environment variables.
Before running a broad test suite, know what it touches.
For unknown projects, start smaller.
Run targeted tests.
Read test setup files.
Inspect scripts before executing them.
Escalate only when the test is worth the access.
This is not paranoia.
This is operator hygiene.
A Team Policy Template
Teams do not need a giant policy to get value.
Start with five rules.
Default local mode is workspace-write.
Network access is off unless approved.
Writes outside the repository require approval.
Publishing and deployment require human confirmation.
Secrets should not be read unless the task explicitly requires them.
That is enough to prevent many sloppy failures.
Then add project-specific exceptions.
Document the exceptions.
Review the exceptions after incidents.
Remove exceptions that stopped being useful.
The policy should be short enough that engineers actually remember it.
Operator Workflow
Start every agent session by naming the task.
Name the repository.
Name the expected write area.
Name the commands that are allowed.
Name the commands that are risky.
Let the agent inspect first.
Let it propose or implement within scope.
Review diffs.
Run targeted checks.
Approve broader commands only when the next step actually needs them.
Publish or deploy as a separate decision.
That workflow keeps autonomy and accountability together.
It also makes the agent easier to trust.
Trust is not blind confidence.
Trust is a well-lit boundary.
Common Mistakes
The first mistake is enabling network access permanently because one task needed it once.
The second mistake is adding broad writable roots to avoid approval prompts.
The third mistake is letting publish, deploy, and delete tools feel like normal editing tools.
The fourth mistake is running unknown scripts before reading them.
The fifth mistake is treating the agent’s confidence as security evidence.
Confidence is not evidence.
Logs are evidence.
Diffs are evidence.
Config is evidence.
Approvals are evidence.
That mindset makes local agents much easier to govern.
FAQ
Is sandbox mode the same as approval policy?
No.
Sandbox mode controls what Codex can technically do.
Approval policy controls when Codex must ask before doing something.
They work together.
Should I keep network access off?
For routine local editing, yes.
Turn it on only when the task needs current internet access, dependency installation, API calls, publishing, or another networked action.
Is workspace-write safe enough?
It is a strong default for ordinary development because it limits writes to the active workspace and configured writable roots.
It is not magic.
You still need review, tests, and approval for risky actions.
When should I use read-only mode?
Use read-only for review, analysis, unfamiliar repositories, sensitive branches, or any task where you want a plan before edits.
Should an AI coding agent be allowed to deploy?
Only with explicit human review and a separate approval step.
Deployment is not just code execution.
It changes external state.
๊ด๋ จ ๊ธ
- Claude Code Subagents vs Hooks: When to Delegate, When to Automate, and When to Stay in the Main Thread
- Workspace Agents๋ GPTs์ ๋ญ๊ฐ ๋ค๋ฅผ๊น: ํ ๊ถํ, ์น์ธ, ๋ก๊ทธ ์ด์ํ
- Codex๋ฅผ ๋ต๋ณ๊ธฐ๊ฐ ์๋๋ผ ์์ด์ ํธ๋ก ์ฐ๋ ๋ฒ
Sources
The point of sandboxing is not to make the agent timid.
The point is to make autonomy legible.
When the boundary is clear, the agent can move faster inside it.
That is the useful version of local AI coding.