Codex extension in VSCode: Completely ignores "Allow every time", no matter how many times I click it - And despite setting to Agent (full access)
Resolved 💬 18 comments Opened Sep 8, 2025 by bar-sharabani Closed Nov 18, 2025
💡 Likely answer: A maintainer (dylan-hurd-oai, contributor)
responded on this thread — see the highlighted reply below.
What version of Codex is running?
VS Code Extension
Which model were you using?
GPT-5
What platform is your computer?
Microsoft Windows NT 10.0.19045.0 x64
What steps can reproduce the bug?
- Enter VS Code.
- Open Codex extension.
- Set reasoning effort to Low or Medium (haven't tested High, but might happen there too).
- Set to Agent (full access).
- Set to Local.
- Write a text prompt to the agent and press Enter.
- When the agent decides to edit, use the dropdown menu to set to "Allow every time" and click it.
- Click it.
- Watch how it keeps asking, repeatedly, for permission to edit files - despite clicking the "Allow every time" button the previous times (doesn't matter if 1, 5, 10, 20 times, etc).
Image:
<img width="320" height="561" alt="Image" src="https://github.com/user-attachments/assets/a6ba6689-3398-4533-8f7c-3369632c9e9d" />
It's as if it ignores the permission I give it to allow it to edit files every time, and keeps asking each time for permission. I've tried restarting VS Code, as well as restarting my PC, and it did not fix it.
What is the expected behavior?
I expect it to stop asking for permission to edit files after the first time I click "Allow every time" - clicking it just once should be enough for it to automatically edit files on its own without asking for my permission.
What do you see instead?
_No response_
Additional information
This bug has been going on for at least 2 days now.
18 Comments
Not 100% sure but what I think "allow every time" means right now, is that any future identical edits will be allowed. Which I don't think is great design as it's rarely executing the exact same changes to the code, or in my case a pwsh script to read files.
I've had success instructing it to complete code edits without permission on Agent (full access) / high
This is my experience as well. It was working fine before but now it wants an approval on every single thing it wants to do. It can take like 20 approvals for a pretty minor change. It seems like a bug. I believe this started happening on Sat or Sunday. I switched to the newly announced gpt-5-codex, same issue. This happens to me with both the CLI (using windows terminal with Powershell) or in the vscode extension (in which powershell is my default terminal).
@BlueRay525 @adrianveen @MetalHexx are you still seeing issues here?
@dylan-hurd-oai
I do. Using on Windows
<img width="582" height="400" alt="Image" src="https://github.com/user-attachments/assets/ff7bcbb7-c4fa-4c98-aab4-f5a475ea8867" />
@VladTheFrontender what version are you on? And it looks like you're still using Agent, not "full access" mode
@dylan-hurd-oai
Oops, with full access the problem seems to be absent. Ty
@dylan-hurd-oai With "Agent" requesting approval to run every single powershell command it is essentially a useless mode. Every "Get-Content" will need to be approved which means you are just clicking to allow the model to search for a string for example. Is that intended?
Excellent, agent (full access) is working as expected without approval. Thank you @dylan-hurd-oai!
I agree with @adrianveen. Sometimes, I like to move slow and not go full automation. Currently, regular agent mode is too granular with its approval needs to be usable at a reasonable pace.
Hello,
I am also having this issue.
Click Allow every time....just pops back up.
I am using Local, Agent Mode, gpt-5-codex (medium). Have not tested this so far with other combinations.
I might be wrong, but I presumed the intended functionality was, in my head 'Allow the Agent permission to edit as required, for this session, within the repo root and subdirectories, without having to click Allow again'.
That makes sense to me, in terms of risk. So any potential carnage is confined to my local version, and only within the folders for that project.
I'd prefer that, rather than having to give 'Full Access' to Codex Agent for this to work, ("When Codex runs with full access, it can edit any file on your computer and run commands with network, without your approval."). That sounds a bit scary to me ;-)
Windows 10
OS Name Microsoft Windows 10 Pro
Version 10.0.19045 Build 19045
VScode
Version: 1.105.1 (user setup)
Commit: 7d842fb85a0275a4a8e4d7e040d2625abbf7f084
Date: 2025-10-14T22:33:36.618Z
Electron: 37.6.0
ElectronBuildId: 12502201
Chromium: 138.0.7204.251
Node.js: 22.19.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.19045
Github Actions extension
Auto Update on, v0.28.0
Codex extension
Auto Update on, v0.4.21
@bolinfest I'm still seeing the behaviour that @interconnectedMe is describing. There is not balance between the two agent modes, it's literally all or nothing. Providing access to a repository/working folder should allow for any non mutating commands like searching or cd'ing somewhere, reading files etc.
Ideally in the regular "Agent" mode, only code (or w.e changes you allow as some sort of options) would require approval. And i don't mean to be harsh, but in the current state the regular agent mode is essentially useless.
Interestingly, this is exactly how the macOS version of VSCode and Codex works. It goes away and does its thing, editing files and modifying code within the directories whilst on Agent mode.
I assumed that this would be the same on Windows...I was wrong.
Closing this in favor of #2860, which is the same underlying problem. We are very aware of this behavior and are working on a fix. In the meantime, you can avoid this behavior by using WSL (Windows Subsystem for Linux).
I am having this problem on MacOS but intermittently. I just set it to chat mode, had a chat then asked it to implement and then I got 10 requests for permissions to edit even though I clicked the "Allow this session"
I've got the same issue here on my Mac as well(also still have the issue on windows but I'll try to keep this somewhat focused). Not sure why @etraut-openai continues to close these issues when there are mountains of evidence suggesting it was never fixed.
@taylordragoo, I'm closing duplicate reports of the same bug. It doesn't help to have dozens of open bug reports for the same issue. Please post additional comments to open bug reports, not closed duplicates.
@etraut-openai let me add a little context to help better understand what's going on.
It seems fairly clear the issue is still reproducible, and I think some confusion is coming from how prior duplicate reports were consolidated:
It appears the issue designated as the primary reference was closed prematurely, despite the underlying behavior continuing.
If there is a specific issue that should serve as the primary reference, I'm happy to consolidate the information there, you just need to decide which one that is and then stick with it.
@taylordragoo, thanks for doing that analysis. We're in somewhat of a holding pattern on this issue until the Windows native sandbox is stabilized and no longer "experimental". That's the primary solution to this problem. If you'd like to try the new sandbox, refer to this documentation for instructions. We welcome feedback and bug reports as we work to stabilize this functionality. Work on this feature is taking some time because it's quite complex, and Windows (unlike Linux and MacOS) don't have off-the-shelf sandboxing mechanisms.
@etraut-openai ah that makes sense, I appreciate you taking the time to explain that as the context helps explain the prior issue closures. Thank you!!