Codex Full Access Is the Wrong First Question

These commands do not grant the same authority:

codex -C C:\absolute\project --sandbox workspace-write --ask-for-approval never
codex --dangerously-bypass-approvals-and-sandbox

The first removes approval prompts while keeping a workspace boundary. The second removes both the approval and sandbox controls. The current codex-cli 0.155.1 help exposes them separately for a reason.

Do not copy either command until the failed boundary is known. When someone asks how to give Codex “full access,” the phrase usually hides a smaller problem:

• approval prompts interrupt a non-interactive run;
• one required folder sits outside the workspace;
• a package manager cannot reach the network;
• a domain allowlist is not being enforced;
• or an external tool wants authority that the shell sandbox does not describe.

Treating all five as the same problem produces a broad permission change that may not even repair the failing gate.

The better first question is:

Which boundary stopped the task, and what is the smallest change that proves it?

Three controls that are easy to confuse

1. Approval routing

Approval policy determines whether Codex can pause and ask before an action. It does not, by itself, decide which files or network destinations the command can reach.

OpenAI's current documentation states that --ask-for-approval never works with every sandbox mode. A read-only run with no prompts is still read-only. A workspace-write run with no prompts is still bounded to its configured workspace and network policy.

2. The command execution boundary

The sandbox or permission profile controls the technical reach of generated commands. That includes filesystem access and, depending on the configuration family, command network access.

This is why workspace-write and danger-full-access are not different prompt settings. They are different execution boundaries.

3. External tool authority

Apps, MCP tools, hooks, browser actions, and other integrations may have their own approval and authorization paths. A shell flag is not a universal permission switch for every connected tool.

Removing shell prompts does not automatically authorize a side-effecting app action. Approving one external action does not necessarily widen filesystem access for later commands.

Translate the symptom before choosing a flag

What the operator actually needs	Narrow first move	What not to assume
Run inside one repository without interactive prompts	--sandbox workspace-write --ask-for-approval never	No prompts does not mean machine-wide write access.
Write to one known folder outside the project	Add that exact path with --add-dir	Do not open the parent drive or user profile.
Let a command reach the internet	Enable command networking in the selected configuration model	Web search availability does not prove subprocess network access.
Enforce a domain allowlist	Enable both profile networking and the network proxy	Domain entries alone do not activate enforcement.
Remove the local sandbox	Use dangerous full access only inside an externally isolated environment	Full access does not diagnose why the original task failed.

This table is a diagnostic order, not a recommendation to escalate through every row.

Network access has two separate switches

The current Codex permission-profile documentation makes an important distinction:

1. network.enabled = true permits commands to use the network.
2. features.network_proxy = true activates enforcement of the profile's domain rules.

With networking on and the proxy off, commands have direct network access and the domain rules do not constrain it. That is not an allowlisted setup, even if the TOML contains an allowlist.

A minimal named-profile shape looks like this:

default_permissions = "project-api"

[features]
network_proxy = true

[permissions.project-api]
extends = ":workspace"

[permissions.project-api.filesystem.":workspace_roots"]
"**/*.env" = "deny"

[permissions.project-api.network]
enabled = true

[permissions.project-api.network.domains]
"api.openai.com" = "allow"

The important idea is not the example hostname. It is that filesystem scope, permission to use the network, and network-policy enforcement remain visible as separate decisions.

Do not mix this permission-profile model with legacy sandbox_mode settings in the same effective configuration. OpenAI currently documents them as alternative configuration families.

What I checked on the current Windows CLI

On September 21, 2026, the resolved local installation reported:

codex-cli 0.155.1

Its main help exposed:

• read-only, workspace-write, and danger-full-access sandbox values;
• on-request and never approval values;
• --add-dir for an additional writable directory;
• --dangerously-bypass-approvals-and-sandbox, labeled extremely dangerous;
• and a separate codex sandbox -P <profile> path for checking a named permission profile.

I also preserved a failed check. Running this:

codex sandbox windows --help

did not display a Windows subcommand reference. The current CLI parsed windows --help as a command to run inside the sandbox, and that attempt failed. The verified current help form is:

codex sandbox --help

That failure is not evidence that the sandbox is broken. It is evidence that remembered syntax can be wrong even when the underlying idea is right. Check the installed CLI instead of copying an old command shape.

A five-minute boundary check

Before editing a real configuration:

1. Resolve every installed Codex command and record the active version.
2. Read the current help for the exact surface you will use.
3. Write down the one missing capability: prompt behavior, file read, file write, command network, or external action.
4. Start from a disposable project with no credentials or production scripts.
5. Test one operation that should succeed and one harmless operation that should be denied.
6. Inspect the resulting artifact outside Codex.
7. Change only one control before the next test.

If the first error changes after several settings change together, stop. You have lost the causal evidence needed to know which boundary mattered.

The practical rule

Use fewer prompts when the problem is prompts. Add one directory when the problem is one directory. Enable and constrain command networking when the problem is networking. Review external tools under their own authority model.

Full access is the last answer because it removes evidence as well as friction.

For the complete Windows decision matrix, current configuration families, default_permissions recovery, network-proxy checks, and rollback boundaries, use the Codex Windows permissions guide.

Sources

• OpenAI: Permissions
• OpenAI: Agent approvals and security
• OpenAI: CLI reference
• OpenAI: Configuration reference

Disclosure: This article was drafted with AI assistance. The product facts were checked against current OpenAI documentation, and the CLI behavior was checked locally on the version named above. No credentials or user configuration were read.