To run Codex without approval prompts, keep the sandbox and approval policy separate. The documented bypass flag removes both safeguards; an approval policy of never can instead leave a restrictive sandbox in place.

If you searched for “Codex dangerously skip permissions,” the exact flag in OpenAI’s current documentation is --dangerously-bypass-approvals-and-sandbox, also called --yolo. It is not the same as simply allowing edits in a working directory.

This guide reflects the Codex security documentation checked October 7, 2026. The commands below are documented examples, not commands we executed.

On this page

Two controls answer different questions

The sandbox determines what a command can technically access. The approval policy determines when Codex asks before carrying out an action.

OpenAI documents a workspace-write sandbox for ordinary repository work. It permits operations within the active workspace while retaining restrictions on other locations and, by default, command network access.

An approval policy can require a prompt for actions beyond those boundaries. Turning off prompts does not automatically turn off the boundaries: Codex must still operate within the sandbox you selected.

That distinction is useful for unattended jobs. A job can fail to complete an operation it lacks permission to perform without waiting for a person to approve it. Removing the sandbox is a different choice.

What the dangerous bypass flag means

OpenAI’s security table describes --dangerously-bypass-approvals-and-sandbox as full access with no sandbox and no approvals, and labels it not recommended.

The alias --yolo refers to that same bypass. A shorter spelling does not create a different isolation mode.

The effect concerns the process running on your machine or runner. It does not grant a repository permission to access an unrelated service, supply credentials it lacks or change the provider’s account permissions. It does remove the local checks that normally constrain generated command execution.

Do not treat this flag as a routine remedy for a failed build. First identify the operation that was blocked and whether the workflow genuinely needs it.

Use the documented workspace mode for repository edits

OpenAI documents this interactive configuration:

codex --sandbox workspace-write --ask-for-approval on-request

It allows ordinary workspace work while retaining approval for actions that need broader access. This is the documented Auto-style combination in the current security guide.

For reading and planning with tighter write restrictions, the same guide gives:

codex --sandbox read-only --ask-for-approval on-request

Choose the mode according to the job. “Make a patch in this repository” and “summarise the repository” do not require identical write permissions.

The documentation also notes protected directories within writable roots, including Git metadata and agent configuration directories. A path being inside the repository does not establish that every part of it is writable.

Unattended runs do not require full access

For a read-only non-interactive configuration, OpenAI’s security table gives this combination of flags:

--sandbox read-only --ask-for-approval never

It preserves the read-only sandbox and disables approval prompts. The job does not receive unrestricted access merely because no person is present to answer.

For automation that needs repository edits, the non-interactive guide directs users to codex exec --sandbox workspace-write. Set the least permissions required by the actual workflow.

The same guide describes older codex exec --full-auto invocations as a deprecated compatibility path that prints a warning. New scripts should use the explicit workspace-write sandbox flag rather than assume an old preset still describes current behaviour.

These examples concern the CLI. Do not transfer their flags into a consumer chat prompt and expect the application’s environment to change.

Network access is another setting

In workspace-write mode, the security guide documents command network access as disabled unless enabled in configuration.

A network request can therefore fail even when file edits in the workspace succeed. That is not evidence that Codex needs the dangerous bypass flag.

The guide also distinguishes the web search tool from network access for spawned commands. Allowing a search does not mean a shell command can contact every host, and a command’s network access does not prove a search tool is enabled.

Before changing permissions, identify whether the blocked operation is a file write, a command requiring broader access or a network connection. The answer determines which setting is relevant.

A container is an outer boundary, not a guarantee

OpenAI discusses running Codex inside a devcontainer when the host cannot provide the normal Linux sandbox. In that arrangement, the container can supply the intended outer isolation boundary.

The same documentation warns that a malicious project can exfiltrate anything available inside a devcontainer when Codex has full access, including Codex credentials. An isolated runner still needs a deliberate decision about mounted files, available secrets and network access.

A container label alone is not proof that the environment contains nothing sensitive. The meaningful question is what the process can actually read, write and transmit.

For routine work, use the restrictive mode that completes the task. If a workflow needs broader access, review that specific requirement and the environment rather than applying a universal bypass.

Sources

OpenAI Developers: Agent approvals & security and Non-interactive mode, checked October 7, 2026. For subscription and usage questions, see the coding-agent plans tracker.