Codex has no clue it needs elevated permission to delete or move files in Agent mode
What version of Codex is running?
codex-cli 0.79.0
What subscription do you have?
Plus
Which model were you using?
gpt-5.2-codex medium
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
In Agent mode (/approvals -> 2), Codex fails to understand that it needs elevated permissions to do remove or move operations. It not only fails to understand, it looks like it doesn't even realize it needs them. The reasoning is usually, "Hm, how weird, I can't delete this file," and then it wastes a ton of time trying to find a workaround.
The same goes for commands like ./gradlew test that might modify something outside the working directory. Instead of asking for elevated permission, it sees that ./gradlew test throws an error saying some cache isn't write-accessible (because of the sandbox), then stops and tells me to delete that cache. In reality, I don't have to delete anything. It just needs elevated write permissions, but Codex is blissfully unaware of that.
The worst part is how time-consuming it is. The AI can spend 15-30 minutes reasoning with itself, trying every hack and workaround it has to bypass the sandbox, and when it ultimately fails, it still never asks for elevated permission. I, the user, have to explain to it every time how it works. This is insane. I shouldn't have to explain to the software how it should operate itself. And I'm not even getting into how much quota it burns every time.
What steps can reproduce the bug?
While in Agent mode, ask Codex to do any task that involves moving or removing files without telling it directly to remove or move files. For example, "Refactor this package."
What is the expected behavior?
The AI should know when to ask for elevated permissions instead of spending 15 minutes and countless tokens trying to find workarounds.
Additional information
_No response_
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Thanks for the feedback. What you're describing here is model behavior, not something under the control of the Codex harness itself. We'll share the feedback with the team responsible for training our codex models. If you see other model behavior that you'd like to report, please use the
/feedbackcommand. That will provide us with additional details including logs and conversation text.Eh, I'm not really convinced it's solely a model issue. What I mean is that the fact that it's "not something under the control of the Codex harness itself" is a problem in itself. Because every time this harness changes the runtime policies, the same issue will emerge over and over again, even after the model is retrained to know that it needs elevated permissions. Like, what happens when it's no longer the case again? Hell, what about locally hosted models by other vendors? The harness supports them too. Do we need to retrain them every time some runtime policy change comes along?
Logically, the harness needs some way to communicate to the model what boundaries it has and how to correctly operate within them, or this issue will keep reappearing with every tiny change. I think it would be more rational, instead of pushing the blame between teams, for you guys to sit together and think it through. It's an infrastructure-level problem.
I mean, of course, who am I to tell you what to do? I understand my place, but you also need to understand: all of this is a useless point of friction. It's weird to have to re-explain to the model how the tool it lives inside actually works. Because if I can do that, why can't the tool itself, right?
I am in complete agreement. I think this issue needs to be reopened.
Additionally, I am under the impression that Codex models are not limited solely to the Codex CLI.
@etraut-openai could you weigh in on this again? I think @wtlgo is making some very valid points here.