Approval mode "read-only" option

This change was intentional and was an attempt to simplify the approval UI, which many users found difficult to understand.

I've changed this from a bug report to an enhancement request, and we can see if it gets upvotes.

I put together a scoped fix that keeps /permissions behavior unchanged, but restores Read Only under /approvals (legacy command). That keeps the simpler default UX while still giving users an explicit read-only path when they ask for approvals directly.

Proposed behavior:

• /permissions on non-Windows: Default, Full Access (unchanged)
• /approvals: Read Only, Default, Full Access

I’ll open a PR and link it here. https://github.com/openai/codex/pull/11931

@yash27-lab, we are not accepting PRs from external contributors. Please review our contribution guidelines. As I mentioned, this change was intended, so we don't consider it a bug.

This change was intentional and was an attempt to simplify the approval UI, which many users found difficult to understand. I've changed this from a bug report to an enhancement request, and we can see if it gets upvotes.

Hi, I strongly believe this is not a good solution for the problem.

I'm working on a complex CUDA/C++ codebase, and quite often Codex attempts to apply incorrect changes, duplicate code, or modifications that lack full context, or bad-performance code in hot paths.

In those situations, I need to review the proposed diff carefully and provide feedback before anything is applied.

With auto-apply enabled, this could severely damage the codebase before I have the opportunity to reject or correct the changes.

For my work, manual review before applying changes is critical.

@CptRenko you can set the trust_level to untrusted in ~/.codex/config.toml. This will return approvals back.

[projects."/Desktop/your_project"]
trust_level = "untrusted"

@CptRenko you can set the trust_level to untrusted in ~/.codex/config.toml. This will return approvals back. [projects."/Desktop/your_project"] trust_level = "untrusted"

@latyshev It is still a pain to change approval modes on the fly. Sometimes you know the model will do everything correctly and you just want to allow it, then switch back to read-only mode.

I can’t believe they removed this option instead of keeping it as a configurable setting. You could still set the default to agent mode.

I believe they should also add a Shift+Tab shortcut to cycle through approval modes, similar to how it works in Claude Code. It’s an excellent feature.

Thanks @latyshev — that’s better than nothing.

That said, I fully agree with @tolgaytoklar. Changing approval behavior on the fly is frustrating and disrupts established workflows.

I don’t understand why the option was removed instead of simply making the new behavior the default while keeping it toggleable. Even if the default had changed, that wouldn’t be an issue — but removing the choice entirely is what makes it problematic.

This change felt abrupt and ended up breaking several workflows that relied on read-only mode behavior. Predictability and explicit control are especially important in complex or sensitive codebases.

Setting sandbox_mode to read-only in config.toml shows a 3rd Option for approvals (Custom) ... upon selecting this the old behavior seems to be restored for me

+1

Need a way to quickly toggle read-only within the same session.

This change was intentional and was an attempt to simplify the approval UI, which many users found difficult to understand. I've changed this from a bug report to an enhancement request, and we can see if it gets upvotes.

No, it isn't. It's a coercion mechanism by which you try to force users to give more control to agents than they want to. I suspect if you didn't fear the backlash from people's systems being thrashed you would force full control. There is no way anyone was ever confused by what read-only permissions meant.

A temporary workaround is probably to limit the program's permissions at the OS level. Although I wouldn't be surprised if they'll check for that and refuse to run to be extra coercive.

Put this back please

Thanks for the feedback. We're discussing options here and are looking at how to bring this back. We want to do so in a way that takes into account the feedback from other users that led us to remove this in the first place.

> This change was intentional and was an attempt to simplify the approval UI, which many users found difficult to understand. > I've changed this from a bug report to an enhancement request, and we can see if it gets upvotes. No, it isn't. It's a coercion mechanism by which you try to force users to give more control to agents than they want to. I suspect if you didn't fear the backlash from people's systems being thrashed you would force full control. There is no way anyone was ever confused by what read-only permissions meant. A temporary workaround is probably to limit the program's permissions at the OS level. Although I wouldn't be surprised if they'll check for that and refuse to run to be extra coercive.

so true bro, i have codex skills disabled and it still tries to use them. going to file a bug report later today

I’m seeing the same issue.
I get nervous when prompting something like “could you do X without making any edits,” because it could still affect or even corrupt my current uncommitted changes.

This change was intentional and was an attempt to simplify the approval UI, which many users found difficult to understand.

I understand that repeated approval prompts can feel annoying to some users and may create support overhead, but that does not mean explicit permission before making changes is unnecessary.

I have a huge codebase and don trust it change all without knowing if is correct or not, and i hate save all the code on git to be able to roll back.. it simple do not have sense

i put read-only on config.toml and now it simple nagate to make anything if i not configure a sandbox to write mode. ??=¿=¿?

I constantly ran into the issue when doing PR reviews, even using the builtin /review didn't stop codex from changing files and complaining about those changes. I have tried yelling REMEMBER: READ ONLY with every input, but that got old fast, leading me to switch away from codex.
Without the read-only option codex is useless as a review tool.

I must go away from using it now. It cannot revert to older versions and gives an error every time. It is unusable; it creates and changes files as it wants. I am waiting for a fix and using Cline in between.

I guess we're canceling our plans and moving to claude. Thank god there's an alternative.

This and https://github.com/openai/codex/issues/9203 together hurts ux a lot for codex where other coding agents don't have similar issues and keeps me away from using codex more.