›_ Codex Issues
Codex Issues / #4212

Windows approval “Allow for this session” isn’t remembered

Open 💬 43 comments Opened Sep 25, 2025 by cpjet64
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.41.0

Which model were you using?

affects all models

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What steps can reproduce the bug?

  1. Start Codex on Windows.
  2. Trigger any non–auto-approved command, e.g. a git init.
  3. In the approval modal choose “Always” / “Approve for this session.”
  4. Let the tool run, then issue the same command again.
  5. Codex asks for approval every time.

What is the expected behavior?

Once I approve “for this session,” any equivalent invocation during that session should run without another prompt.

What do you see instead?

Codex repeats the approval prompt because the stored command vector only matches the PowerShell-wrapped version that actually ran, not the original bash -lc … the UI shows and the model reuses.

Additional information

Bug reproduces reliably on Windows because exec command translation swaps the command vector before caching. Broad fix is to store both the displayed command and the executed command when the user approves “for this session.”

View original on GitHub ↗

43 Comments

beestinger72 · 9 months ago

pain in the neck for a first time user

densy07 · 9 months ago

i have to use WSL

panthernet · 9 months ago

I have to use FullAccess for now and I'm scared

Weijiang-Xiong · 9 months ago

I have the same problem with MacOS and Win10, I'm sshing to a Linux computer.

kuravista · 9 months ago

i have same problem to..always clikc "aprove this session" every time. when forget use fullaccess

tariqkhan051 · 9 months ago

same issue, even after clicking 'approve this session', it's asking again and again

stavBodik · 9 months ago

Same here, Wating for fix, thanks developers !

TVpoet · 9 months ago

same, please fix it

jfbosch · 9 months ago

Same on win 11.

YanX94 · 9 months ago

Same Win11

joserachetti · 9 months ago

Same problem on Win 10

MrGeRoI · 9 months ago

I'm using full acess but i'm afraid it will mess up everything somehow

Abdelkrim · 9 months ago

It is not normal that we have either to click on "allow this sessions" several times per prompt and grant access to the current project or to grant full access to our file system.

this is not an acceptable choice !

click on "Allow this session" should grant access to the current project only !

<img width="510" height="293" alt="Image" src="https://github.com/user-attachments/assets/fe912521-6c79-4a8a-803c-12f82b55a8ca" />

Karamann · 9 months ago

so this is offiicially a bug?

interconnectedMe · 9 months ago

(just posted this here also - https://github.com/openai/codex/issues/3325#issuecomment-3433510602 )

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

raphael-devel · 9 months ago

This issue affects all operating systems — Windows, macOS, and Linux — not just Windows as currently labeled.

danalvarez · 9 months ago

Bump. Same issue. I feel like there should be a way of letting codex edit any file in my workspace without approvals. I have a git repo so I can clearly see what it changed and if I dont like it, I just roll back. It makes no sense in this case to have to approve every step as it works, just let me see the final product!

Pleeeeease fix it! Would make this tool 1000% more usable. As it is now, I cant do anything else while its working, because I have to be switching back just to approve.

p.s. dont want to use agent (full access).

jfbosch · 9 months ago
Would make this tool 1000% more usable.

Agreed. I completely stopped using it because of this behavior, while I really, really would like to use it.

wolfgangihloff · 8 months ago

I also get this issue and it makes me NOT want to use Codex, while the performance is overall good, having to approve simple edits in agent mode?

Same as @jfbosch not usable like that, only get the pull request review benefit out of codex right now.

0.4.43
macosx 15.6.1 (24G90)

spin0za · 8 months ago

Still not fixed!

danalvarez · 8 months ago

For me this has been fixed for a couple of weeks now. I don't know why some people are saying it's still not fixed. Since moving to WSL it is now very, very usable, and never asks for permissions. I am using 0.4.43 of the VSCode Codex extension.

etraut-openai contributor · 8 months ago

Yes, this should work fine if you're using WSL. It's still a problem with native Windows (without WSL). We're working on fixing that.

wolfgangihloff · 8 months ago

What about MacOSX?

On Tue, Nov 18, 2025 at 1:09 AM Eric Traut @.***> wrote:

etraut-openai left a comment (openai/codex#4212) <https://github.com/openai/codex/issues/4212#issuecomment-3544599964> Yes, this should work fine if you're using WSL. It's still a problem with native Windows (without WSL). We're working on fixing that. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/4212#issuecomment-3544599964>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABHXAAZXASUCFV7LNLO2BT35JWUNAVCNFSM6AAAAACHOHRMOGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBUGU4TSOJWGQ> . You are receiving this because you commented.Message ID: @.***>
gravewhisper · 8 months ago

project is in WSL while vscode is in windows. experiencing the same.

edit: resolved on my end as of nov 24, 2025 10:06 PM utc

wolfgangihloff · 8 months ago

On MacOSX isssue is resolved with 0.4.46

utkesmer · 7 months ago

Pain goes on...

sandeep-chaps · 7 months ago

I have the same issue, VScode running on Windows with remote SSH to a Linux Box.
NAME="Rocky Linux"
VERSION="9.4 (Blue Onyx)"

m0Zahed · 7 months ago

Dawg pls fix this

Dgaylard · 7 months ago

Guys this is a really bad user experience effecting a LOT of users, can we please get this fixed? otherwise I'll just go back to Windsurf frankly.

Maxed-Out-99 · 7 months ago

Still an issue for me. It's fine at first but quickly I don't want to baby sit it when I'm literally just smashing approve without even looking at the code.

nam37 · 7 months ago

Still seeing this on Windows 11.

Maxed-Out-99 · 7 months ago

Chatgpt helped me install wls and run vs code from there. Had to put my project there which is not ideal but at least I can give a task and leave and it will be done when I come back 👍

evenfrost · 6 months ago

This is still an issue with Cursor + Codex extension.

Codex extension version: 0.4.56
Cursor Version: 2.3.14
VSCode Version: 1.105.1
Commit: b3e9fe6c37659159fc2dec9ae643d74c25e5d0d0
Date: 2025-12-29T23:26:25.365Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Linux x64 6.17.0-8-generic
moritonal · 6 months ago

Still happening for new Windows user. For large changes it makes the extension very annoying to work with

christopherjnash · 6 months ago

Also still having the same problem unfortunately... Anybody have a workaround that doesn't include WSL use?

baochenw · 6 months ago

Also still having the same problem on VS Code extension 0.4.58

felipekjr · 6 months ago

Still happening on Ubuntu 20.04 and VS Code

Jason5Lee · 6 months ago

Still happening on Windows. While working fine on macOS.

etraut-openai contributor · 6 months ago

@Jason5Lee, have you tried enabling the Windows experimental sandbox?

Olyno · 6 months ago

Funny enough, i have the exact same issue on Fedora, Linux, via Codex CLI.

It looks like Codex fails to edit a file properly, and it asks for permission, but when you select Yes, and don't ask again for these files, it keeps asking for this file. Kinda annoying.

moritonal · 6 months ago

Just a note for others, on my Windows machine with extension openai.chatgpt:0.4.60, I'm finding that if I edit C:\Users\user\.codex\config.toml and manually add 

[notice]
hide_full_access_warning = true

[projects.'C:\Users\user\Documents\GitHub\ProjectABC']
trust_level = "trusted"

Then it massively reduces the number of permission requests. However it still _sometimes_ asks me for permission to write to files?? In these cases you can see in the console output the following:

[error] [CodexMcpConnection] CLI: codex_core::codex: needs_follow_up: true
[info] Received app server notification: codex/event/token_count
[info] Received app server notification: thread/tokenUsage/updated
[info] Received app server notification: account/rateLimits/updated
[info] Received app server notification: codex/event/patch_apply_begin
[info] Received app server notification: item/started
[info] Received app server notification: codex/event/apply_patch_approval_request
[info] Received server request: 1 item/fileChange/requestApproval object(keys=5)

So one idea is that it's the backend that's driving the permission checks which also implies it could be per-model based, I'm on 5.2.

WAY29 · 6 months ago

same in WSL and vscode plugin

SylvainWinning · 1 month ago

I took another pass through this thread and the current reports. This issue may benefit from an explicit status split, because the comments now seem to cover more than the original Windows command-vector mismatch.

The original report points to a concrete class of bug: the user approves the displayed command “for this session”, but the cached approval matches the translated/wrapped command that actually ran. On native Windows, where commands may be rewritten through PowerShell/cmd wrappers, that can make the next equivalent request miss the session approval.

A focused regression test could cover:

  1. User-facing command is bash -lc ... or equivalent displayed text.
  2. Execution command is translated/wrapped for native Windows.
  3. User selects AcceptForSession.
  4. A later equivalent model request matches the prior approval whether it is compared against the displayed command, the executed command, or the normalized command identity.

It would also help to separate the remaining reports by environment:

  • native Windows without experimental sandbox;
  • Windows + WSL remote workspace;
  • VS Code remote SSH into Linux;
  • macOS/Linux reports that may actually be file-change approval rather than command approval;
  • item/fileChange/requestApproval / apply_patch_approval_request cases, which may be a separate path from command execution approvals.

That split could make it clearer whether this issue should stay focused on command approval caching, or whether a second issue is needed for file-change approval repetition.

Per docs/contributing.md, I’m sharing analysis rather than opening an unsolicited PR. If maintainers want a repro artifact, the command-normalization regression test above seems like the smallest useful starting point.