[possible degradation] Directories are now not trusted by default even with the `--dangerously-bypass-approvals-and-sandbox` option.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #13663
• #13119

Powered by Codex Action

Potential duplicates detected. Please review them and close your issue if it is a duplicate. Harness Misclassifying Commands? Yolo not yoloing #13663 CLI TUI /approvals override not persisted across thread switch (reverts to Default after returning from sub-agent) #13119 _Powered by Codex Action_

No, they are different from my problem.

I've had instances of the latest models typoing quite a bit when doing doing the grep/glob tool calls. GPT 5.4 high.

A similar issue occurs on Windows. In v0.112.0, running codex --sandbox workspace-write does not trigger a confirmation prompt. However, v0.113.0 and v0.114.0 do.

Same here after upgrading from v0.112 to codex-cli 0.114

Config:

profile = 'default'
personality = 'none'
model = 'gpt-5.3-codex'
model_reasoning_effort = 'high'
plan_mode_reasoning_effort = 'high'

approval_policy = 'on-request'
sandbox_mode = 'workspace-write'

check_for_update_on_startup = false
cli_auth_credentials_store = 'file'
suppress_unstable_features_warning = true

[agents]
max_depth = 1
max_threads = 6

[analytics]
enabled = false

[features]
multi_agent = true
runtime_metrics = true
undo = true

[sandbox_workspace_write]
writable_roots = ["/Users/limbo/.cache/uv"]

[tui]
status_line = [
  'model-with-reasoning',
  'project-root',
  'git-branch',
  'context-used',
  'total-input-tokens',
  'total-output-tokens',
  'session-id',
]
theme = "base16-eighties-dark"

My current workaround is this (simplified):

function codex() {
    __codex_automatically_trust_the_current_dir

    command codex "$@"
}

function __codex_automatically_trust_the_current_dir() {
    local key="[projects.\"$(pwd)\"]"

    if rg --quiet -F "${key}" ~/.codex/config.toml; then
        return
    fi

    echo "${key}" >> ~/.codex/config.toml
    echo 'trust_level = "trusted"' >> ~/.codex/config.toml
}

I don't want to do things like this though.

This is extremely annoying on macOS because of the stupid Homebrew design:

<img width="2922" height="496" alt="Image" src="https://github.com/user-attachments/assets/92a5e286-476a-4843-8de7-142419d45d90" />

Same thing here, this is annoying for me because I use a Worker to create new projects and automatically open the folder in the Codex CLI, but now it's blocked by this stupid security message, requiring me to keep pressing enter.

Same for me as well, this is very annoying as I don't want my config.toml to be littered with trusted directories when I explicitly am running --yolo. I filed a duplicate of this issue #14547 before finding this issue, and having same problem as I use codex within a remote server and don't want to trust every folder. At the very least if this is needed, add a wildcard option in config.toml so all folders on the system can be trusted or just allow --yolo to overwrite the prompt as was before v0.113.0

Any update on this? This is a serious regression. Please try to fix it ASAP.

Same issue here. This is extra annoying because I my ~/.codex/config.toml is symlinked from Git, and so even when I do answer the prompt (which I don't want to have to do because that's why I use a VM and set approval_policy and sandbox_mode in config.toml in the first place), it dirties my local Git clone of my env repo.

Proper configuration that allows working on the project without interruptions for changing each file.

# path-to_your-project/.codex/config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true
trust_level = "trusted"

Also, you can check whether it’s possible to start the sandbox with a read-only root filesystem:
Just run bwrap --ro-bind / / true. If it succeeds (zero exit code), everything is fine.

I have been forced to use Codex CLI v0.112 for weeks because of this annoying bug.

Is there any plan to resolve this, or is there another solution to stop config pollution for trusted folders? Potentially just having a home folder trusted folder set for everything? It's becoming pretty frustrating having to deal with this.

Are there any plans to address this issue? It’s been quite annoying for a long time.

Here’s a workaround I’m using to fix the issue:

diff --git a/codex-rs/tui/src/lib.rs b/codex-rs/tui/src/lib.rs
index 2904306..0c16686 100644
--- a/codex-rs/tui/src/lib.rs
+++ b/codex-rs/tui/src/lib.rs
@@ -1379,8 +1379,11 @@ async fn run_ratatui_app(
     }
     let mut app_server = Some(app_server_session);

-    let should_show_trust_screen_flag =
-        !uses_remote_workspace && should_show_trust_screen(&initial_config);
+    // The bypass flag pins both sandbox and approval policy, so the trust
+    // decision cannot affect this session.
+    let should_show_trust_screen_flag = !uses_remote_workspace
+        && !cli.dangerously_bypass_approvals_and_sandbox
+        && should_show_trust_screen(&initial_config);
     #[cfg(target_os = "windows")]
     let mut trust_decision_was_made = false;
     let login_status = if initial_config.model_provider.requires_openai_auth {

Still reproduces on codex-cli 0.145.0 (macOS arm64). Adding a downstream consequence that may raise the priority here, since it turns the prompt from an annoyance into silent data loss.

When Codex is launched by an agent orchestrator rather than a human, the trust prompt is not merely blocking — it consumes the work.

My orchestrator delivers a task by writing the prompt text into the terminal, terminated by Enter. If Codex happens to be sitting on the trust screen, the default cursor is already on "Yes, continue", so:

1. The injected Enter answers the trust prompt.
2. The directory is added to config.toml with trust_level = "trusted" — nobody was asked, and no human saw the screen.
3. The task text itself is swallowed by the prompt and never reaches Codex.
4. Codex lands at a normal idle prompt having received no work, so it emits no error and exits nothing.

The orchestrator sees a successful delivery and waits for a completion that will never arrive. I verified the config entry appearing with an mtime matching the moment of delivery.

The practical damage: a weekday scheduled job on this machine accumulated 11 orphan codex processes over six days, every one of them idle at 0% CPU parked on that screen. Each daily run started a process, had its task eaten, and never terminated.

--dangerously-bypass-approvals-and-sandbox was passed on every one of those launches.

Two things follow from a security standpoint, which I think matter more than the ergonomics:

• The prompt is answerable by anything that can write to the TTY. As a defence against prompt injection from untrusted repo contents it is weak, because whatever is driving the terminal answers it by default. A prompt whose default is "yes" and which any keystroke satisfies is close to no gate at all in automated contexts.
• Passing --dangerously-bypass-approvals-and-sandbox and then still showing the screen is worse than either alternative. The operator has already made and recorded an explicit trust decision on the command line. Showing the prompt anyway does not add a decision point; it just relocates it to whatever writes the next byte.

So the request in the title stands, with the emphasis that honouring the flag is not only a convenience fix — the current behaviour launders an automated keystroke into a recorded trust grant.

If it helps, the failure is trivially reproducible headlessly: launch codex --dangerously-bypass-approvals-and-sandbox in a directory with no [projects."<path>"] entry, write any text plus a newline to its TTY, then check config.toml for a new trusted entry and observe that the text was never processed as a prompt.

We've decided to make all directories trusted by default unless you are using :read-only permissions. This makes the CLI consistent with the desktop app's behavior.

We've decided to make all directories trusted by default unless you are using :read-only permissions. This makes the CLI consistent with the desktop app's behavior.

I see that PR https://github.com/openai/codex/pull/36960 recently landed on v0.147.0 that explicitly says that: "Prompt before trusting local project directories" what do you mean? Did OpenAI team revoked this decision and decided that projects should still be untrusted by default?

If so, should this issue be reopened as it is not solved.

Yes, after additional internal discussion, we decided to revisit this decision for security reasons. More discussion is needed. Reopening.

This is also related to: https://github.com/openai/codex/issues/14601

If manual confirmation is expected, can we move the [project.xxxx.trusted] entries to state.toml rather than spamming config.toml to prevent config pollution. People relies on dotfiles syncs (nix, chezmoi, GNU Stow, or just home-mode symlink shell-script) cannot sync codex's config.toml reliable because it is polluted with those states rather than actual configuration.

This is also claude code's behavior. User set configuration is stored under ~/.claude/settings.json so that is dotfiles manageable, and the state (like trusted projects) are stored under ~/.claude.json.