workspace-write sandbox ignores approval_policy, always uses on-failure

Open 💬 0 comments Opened Feb 16, 2026 by KKonyo

What version of Codex CLI is running?

codex --0.101.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.3-codex

What platform is your computer?

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

Windows Terminal (WSL)

What issue are you seeing?

When I start Codex with my intended workspace-write + untrusted setup via alias/profile/config override, Codex starts with workspace-write + on-failure instead.
Notably, launching directly with explicit codex --flags for my intended setup works, but the alias path does not.

What steps can reproduce the bug?

  1. Create an alias/function for intended setup, for example:

codexdev() {
codex -c sandbox_mode=workspace-write -c approval_policy=untrusted "$@"
}

  1. Run codexdev and check startup permissions.
  2. It starts as workspace-write, on-failure (not untrusted).

Also reproducible with:

  1. Profile:

[profiles.dev]
sandbox_mode = "workspace-write"
approval_policy = "untrusted"

Then run:

codex -p dev

  1. Config overrides:

codex -c sandbox_mode=workspace-write -c approval_policy=untrusted

Control check:

  • Direct explicit flags for intended setup work:

codex --sandbox workspace-write --ask-for-approval untrusted

  • But alias-based startup does not preserve untrusted.

What is the expected behavior?

Any startup path (alias/function, profile, or -c overrides) that sets:

  • sandbox_mode=workspace-write
  • approval_policy=untrusted

should start Codex with exactly workspace-write, untrusted, without silently changing to on-failure.

Additional information

_No response_

View original on GitHub ↗