PowerShell 5.1 AuthorizationManager check failed before script execution inside a restricted Codex environment

Question

PowerShell 5.1 AuthorizationManager check failed before script execution inside a restricted Codex environment

Boris Tiomkin 0

Specific local PowerShell script invocations inside a restricted Codex environment fail before the script body starts. Basic PowerShell commands still work, so this is not a general PowerShell failure or a Windows Update installation failure.

Reported environment:

Windows build 26300.9711; installed updates KB5127648 and KB5127694.
Windows PowerShell 5.1.26100.9711 is used for the failing invocation.
ChatGPT desktop app updated to 26.1016.51333.
Latest reproduction: October 21, 2026 at 07:30 UTC (10:30 UTC+3).
Errors: AuthorizationManager check failed; UnauthorizedAccess; SecurityError. Exit code 2, before the script body starts.

The problem was first noticed around updates installed on October 16–17, but a causal link has not been established. Restarting and the app update did not resolve it. Harmless checks work in PowerShell 7.6.7, but those are not equivalent to running the failing script. No security settings were changed for this test. OpenAI support is investigating the Codex environment separately.

Which read-only Windows-side evidence can distinguish execution-policy or zone-validation failure from WDAC/AppLocker/Code Integrity enforcement or Microsoft Defender/AMSI blocking in this scenario? Please identify relevant log channels and event IDs, and any known issue matching these versions. I am seeking a targeted diagnosis that preserves protections, not instructions to disable security or bypass a sandbox. No source code, raw logs or personal paths are included.

0 comments

1 answer

Your answer

Answer 1

Dear Boris,

Thank you for posting your question to the forum community.

The error alone does not identify which protection rejected the script. The most useful evidence is the effective execution policy in the failing PowerShell 5.1 process, the script’s zone and signature information, and security events matching the failure timestamp. Your PowerShell 7 checks do not establish whether the same script would pass authorization.

1. Check execution policy and file metadata

Where the environment permits, run these read-only checks through the same restricted PowerShell 5.1 launch context:

$PSVersionTable
$PSHOME
Get-ExecutionPolicy
Get-ExecutionPolicy -List
$ExecutionContext.SessionState.LanguageMode

For the affected script, substitute its actual path locally:

Get-Item -LiteralPath 'C:\path\script.ps1' -Stream Zone.Identifier
Get-AuthenticodeSignature -LiteralPath 'C:\path\script.ps1'

Successful individual commands do not rule out execution-policy restrictions: Microsoft documents that Restricted permits commands while preventing scripts. Check both the effective policy and its scopes, rather than relying on results from a separate interactive session.

Microsoft also documents this exact error when Windows Shell APIs used for script-zone validation are unavailable or unresponsive. That makes zone validation a possibility, not a confirmed diagnosis of your Codex environment. Finding a Zone.Identifier stream alone would not prove the cause either. Microsoft execution-policy documentation. Microsoft Learn

2. Correlate the Windows security events

In Event Viewer, look under Applications and Services Logs → Microsoft → Windows, around 21 October 2026, 07:30 UTC. Account for Event Viewer displaying local time.

Channel	Relevant events and interpretation
AppLocker → MSI and Script	8007: AppLocker blocked the script/MSI. 8006: audit only; would have blocked. 8005: allowed.
--------	--------
AppLocker → MSI and Script	8007: AppLocker blocked the script/MSI. 8006: audit only; would have blocked. 8005: allowed.
AppLocker → MSI and Script, for App Control/WDAC	8029: enforcement-mode script-policy rejection. 8028: audit equivalent. 8038: associated signature information.
CodeIntegrity → Operational	3077: enforced App Control block of an executable, DLL or driver. 3076: audit equivalent. 3089: associated signature information.
AppLocker → EXE and DLL	8004: executable/DLL blocked. 8003: audit equivalent. Check whether a dependency, rather than the script itself, is named.
Windows Defender → Operational	1116: malware or potentially unwanted software detected. 1117: action taken; inspect the recorded action rather than assuming it was blocked.

An important distinction: Microsoft cautions that 8029 does not always mean execution stopped completely. The script host controls enforcement and may instead impose restrictions such as Constrained Language Mode. Audit events likewise do not demonstrate an actual block. App Control event reference, AppLocker event reference. Microsoft Learn

For Defender events, inspect the Detection Source, process, affected resource and action. A matching detection whose source is AMSI would support that diagnostic path; an unrelated Defender event would not. Defender event reference. Microsoft Learn

Correlate the named file, process ID, policy/rule identifier and, where available, Correlation ActivityID. Missing events alone do not rule out enforcement if the relevant logging was unavailable or records were overwritten.

3. Known issue and next step

I could not verify a published Microsoft advisory matching this exact PowerShell/Codex failure. The KB5127648 release notes do not identify this specific symptom, so the installation timing is not enough to attribute it to that update. Microsoft Support

Share the correlated findings privately with the existing OpenAI support case. If Windows enforcement events identify a block, your security administrator or Microsoft Support can investigate that policy decision. There is no need to weaken protections to collect this initial evidence.

If this helped, I’d appreciate a Like so others can find the answer more easily.