Harness Misclassifying Commands? Yolo not yoloing
What version of Codex CLI is running?
codex-cli 0.111.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.3-codex
What platform is your computer?
Win 11 x64
What terminal emulator and version are you using (if applicable)?
_No response_
What issue are you seeing?
Codex is repeatedly asking for permissions to write/edit files it should already have access to, as they are inside of the repo's folder.
- Giving it full permissions does not fix it
- Restarting the TUI does not fix it
- Yolo does nothing (but it does search the web for seemingly nothing when given this or full perms)
- Saying it always has permissions for the rest of the session never seems to take
It's not clear what is triggering this, it worked fine for long enough to make me think it was resolved, and then I check what it's been up to and see that it's been sitting on a permissions prompt the entire time (no notification sound is triggered).
When asked "Why is everything asking me for permission again? You should have full permissions to everything inside this folder", it claims:
You’re right. The prompts are coming from sandbox escalation, not from repo ACLs. I can write inside C:\Users\snip\Development\snip, but when a command is classified as needing elevated/special execution, the harness asks you anyway. I’ll avoid escalated paths and stick to in-repo, non-escalated edits/commands so you stop getting those permission popups. I’ll keep everything strictly repo-relative and non-escalated from here so those prompts stop.
And then I am immediately asked for permission when it continues 😭 It is at least trying different methods of specifying file locations but none of them make any difference. I have not found a way to tell it to work that avoids this. It happens for at least these methods:
C:\Users\snip\Development\snip\whatever.objc3~\Development\snip\whatever.objc3whatever.objc3
Happens with built in commands and any mcps that offer the same. After some time, all 3 variations work fine until it randomly starts happening again. I cannot determine any consistent pattern or cause and could not even offer a guess.
Additionally, sub-agent permissions requests (that should not happen for the same reasons) are not bubbling up or indicated in the /agent switcher. The main agent interpets this as stuck agents and closes them out after not getting a response and takes over their half-completed work w/o any information from them, making even more of a mess. It defaults to not using sub-agents at all because of this.
What steps can reproduce the bug?
Use codex as normal
What is the expected behavior?
It doesn't do this
Additional information
This bug is completely handicapping codex. It goes from being one of the coolest things I've ever done on a computer to an exceptionally frustraiting claude-tier experience. I'm unable to focus on the big picture as I have to sit here and press a.
Can we _pleaaaase_ yeet with just a little more accuracy? I understand there's so much going on right now. Take your time. Good luck with your heisenbug. I'm seeing a post where I am being instructed to automate the thing I have spent the most time on this week. Out of respect I will not be automating filing bugs.
"You miss 100% of the yeets you don't write comprehensive test cases for" - Sun Tzu
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗