[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 {