Repository navigation
Windows execpolicy false positive when Start-Process and an unrelated URL appear in the same PowerShell script #40060
Description
What version of Codex CLI is running?
codex-cli 0.146.0
The failure was reproduced on 0.146.0. I also checked the latest stable release, 0.149.0, and the current main branch; both still contain the same relevant classifier logic described below.
What subscription do you have?
Pro
Which model were you using?
gpt-5.6-sol
What platform is your computer?
Microsoft Windows NT 10.0.26100.0 x64 (Windows 11 Professional)
What terminal emulator and version are you using (if applicable)?
Windows Terminal, PowerShell 7.6.3
Codex doctor report
The full report contains private local paths, so the relevant redacted fields are included below. All relevant runtime, config, auth, sandbox, and installation checks were OK; the overall warning was an unrelated update-status warning.
{
"schemaVersion": 1,
"overallStatus": "warning",
"codexVersion": "0.146.0",
"runtime": {
"platform": "windows-x86_64",
"installMethod": "npm"
},
"config": {
"model": "gpt-5.6-sol",
"modelProvider": "openai"
},
"system": {
"os": "Windows 10.0.26100 (Windows 11 Professional) [64-bit]"
},
"terminal": {
"terminal": "Windows Terminal",
"powershell": "7.6.3"
}
}What issue are you seeing?
On Windows, execpolicy falsely classifies a benign compound PowerShell script as a dangerous URL launch when the script contains both:
- a local
Start-Processinvocation with no URL argument, and - an unrelated
Invoke-RestMethodcall to an HTTP URL later in the script.
With approval policy never, Codex rejects the command before PowerShell starts:
"C:\Program Files\PowerShell\7\pwsh.exe" -Command '...'
rejected: blocked by policy
The rejection is immediate (Wall time 0.0 seconds). Running the local Start-Process command by itself succeeds, and running the HTTP probe by itself succeeds. Combining them in one PowerShell script triggers the rejection.
This affects a common local-development pattern: start a local application or development server, then poll its loopback health/CDP endpoint until it is ready.
What steps can reproduce the bug?
-
Run Codex on Windows with approvals disabled, for example:
codex -a never -s danger-full-access -
Ask Codex to execute this single PowerShell tool command:
$process = Start-Process ` -FilePath "$env:SystemRoot\System32\cmd.exe" ` -ArgumentList @('/c', 'exit', '0') ` -WindowStyle Hidden ` -PassThru try { Invoke-RestMethod ` -Uri 'http://127.0.0.1:9/health' ` -TimeoutSec 1 } catch {} $process.Id
-
Observe that Codex rejects the entire command with
rejected: blocked by policybeforepwsh.exeruns. -
Execute the
Start-Processportion and theInvoke-RestMethodportion as two separate Codex tool calls. Both are allowed, confirming that the combination is what triggers the false positive.
What is the expected behavior?
Execpolicy should only classify Start-Process as a dangerous URL/ShellExecute launch when an HTTP/HTTPS URL is an argument of that Start-Process invocation (or otherwise belongs to the same command expression).
An unrelated URL used by a separate Invoke-RestMethod command should not cause a local executable launch to be rejected.
The truly dangerous case must remain blocked:
Start-Process 'https://example.com'Additional information
The apparent root cause is in is_dangerous_powershell_words. It computes has_url across the full flattened token list and independently checks whether any token contains start-process:
As a result, the URL and Start-Process token do not need to belong to the same command. The same implementation is still present on main:
When the heuristic marks the command dangerous and approval_policy is never, the decision becomes Forbidden:
https://github.com/openai/codex/blob/rust-v0.149.0/codex-rs/core/src/exec_policy.rs#L728-L741
A regression test could assert that this is not dangerous:
Start-Process local.exe; Invoke-RestMethod http://127.0.0.1:1234/healthwhile preserving the existing test that Start-Process 'https://example.com' is dangerous. A robust fix would associate URL arguments with the specific PowerShell command/AST node rather than scanning the whole script token set.
Related PowerShell execpolicy/parser reports, but not duplicates of this false positive:
Activity
Generoustandard commentedon Aug 27, 2026
Additional Windows desktop occurrence, observed on 2026-08-27. This appears closely related, with one variation: the unrelated HTTPS URL was an environment configuration value, not a health-probe URL.
Environment
sandbox_mode = "danger-full-access",approval_policy = "never".Observed operation
The user authorized an isolated loopback QA backend while preserving the existing development server and user data. One PowerShell tool invocation combined unused-port/non-existing-directory checks, isolated QA storage creation, process-local test environment assignments, and a local Python/Uvicorn launch with
Start-Process -WindowStyle Hiddenand redirected logs.Abbreviated, redacted command shape below. This is not a verified minimal reproduction: paths and the API-base value are placeholders; the original invocation also contained the checks and other assignments described above.
The URL was not an argument to Start-Process. It was child-backend configuration; no URL/ShellExecute launch was intended. No API key literal was present in the command.
Actual result
The entire tool invocation was rejected before PowerShell was created:
Explicit user re-authorization and repetition of the same launch request did not change the result. No QA runtime directory or QA listeners were created. The existing server was unchanged; frontend launch and browser acceptance tests were not attempted.
An additional diagnostic placed the original command in a single-quoted here-string and passed it as data to
codex execpolicy check --rules ... -- pwsh.exe -Command <command>. That outer tool invocation was also rejected before execution. This is not anexecpolicy checkverdict: the checker never ran and no matched-rule information was obtained.Successful controls and limits
git status, Python tests and production frontend builds succeeded in the same task; version-only CLI invocations also succeeded.Please check whether this is the same whole-script
Start-Process+ unrelated-URL heuristic in the desktop app-server version above. An actionable denial reason/rule identifier would help distinguish an intended restriction from a false positive without changing safety settings. Protection against actual URL/ShellExecute launches should remain intact.No private project name, username, real local path, credentials, customer data, full config file, or session transcript is included.
SANDRA136252 commentedon Sep 4, 2026
Additional sanitized Windows desktop occurrence observed on 2026-09-04. The command shape appears closely related to this issue, including the environment-variable URL variant in the earlier comment. The effective denying rule/classifier has not been confirmed for this occurrence.
Environment
OpenAI.Codex 26.901.1978.0; the same rejection persisted after a normal user restart also updated the package to26.901.2854.0.0.153.0-alpha.5; this is task metadata, not an independent version query of the post-update executable.sandbox_policy.type=danger-full-access,permission_profile.type=disabled,approval_policy=never, andapprovals_reviewer=user.Observed operation
The user authorized a local-only development-server launch. A compound PowerShell tool invocation checked unused ports and fresh log paths, set frontend environment variables, and used
Start-Processto launch the installed local Node/Vite entry point on loopback.The HTTP URL was assigned to
VITE_API_PROXY_TARGET; it was not an argument toStart-Processand no URL/ShellExecute browser launch was intended.Abbreviated, path-redacted shape below, not a separately tested minimal reproduction. The original invocation also contained the preflight checks, Git revision lookup, and additional frontend environment assignments described above.
Actual result and checks
The tool returned immediately, before the submitted PowerShell command executed:
Could maintainers confirm whether the whole-script
Start-Processplus unrelated-URL classification discussed here applies to these desktop versions, and identify a supported fix or review path? If this action is intentionally restricted, an explicit reason would help distinguish that from a false positive. Protection against actual unsafe URL/ShellExecute launches should remain intact.No private project identifiers, personal filesystem paths, credentials, database contents, raw logs, task/session IDs, or complete conversation are included. This comment is submitted with the account owner's permission.
baul9265-a11y commentedon Sep 5, 2026
Additional sanitized Windows desktop occurrence observed on 2026-09-04 UTC (2026-09-05 locally). This is consistent with the command shape in this issue; the effective denying rule has not been confirmed.
Environment:
--versionquery of the executable belonging to the currently running desktop app-server: codex-cli 0.153.3. This is a post-incident query, not proof of the exact incident-time engine version.approval_policy=neverandsandbox_policy.type=danger-full-access.Observed operation:
A single PowerShell tool invocation performed loopback-only HTTP status/model-identity probes, checked local resource availability and fresh log paths, and then used
Start-Process -WindowStyle Hiddento launch an existing local PowerShell test script with redirected stdout/stderr. The HTTP URLs belonged to the status probes; they were not arguments to Start-Process.The entire invocation was rejected immediately:
No launcher logs or new local-model inference calls were produced. Ordinary read-only file, Git, and version queries work. The returned error and inspected logs provided no rule identifier or actionable rationale.
The current upstream
is_dangerous_powershell_wordsimplementation still checks for a URL anywhere in the flattened token list alongside Start-Process. This is supporting evidence, not confirmation of which rule the desktop build applied.No permission settings or rule files were changed, and no split-command, alternative-launch, or retry workaround was executed. A minimized reproduction has not been run for this occurrence.
Could maintainers confirm whether this is the same classifier issue and identify a supported fix or review path? Protection against unsafe URL/ShellExecute launches should remain intact.
Submitted with the user's authorization. No private project identifiers, personal paths, credentials, model prompts/responses, raw logs, or task/session IDs are included.
chad20262109 commentedon Sep 5, 2026
Confirmed another occurrence on Windows desktop with codex-cli 0.153.4 (desktop package
OpenAI.Codex 26.901.5280.0), with a proposed source fix and regression tests below.Observed failure
The rejected invocation configured a loopback origin in an environment variable and launched a local server executable. The URL was not an argument to the launch command. The following is a sanitized representation, not a separately executed minimal reproduction:
The tool rejected the invocation before creating PowerShell:
The corresponding runtime log records
approval_policy=Neverandsandbox_policy=DangerFullAccess. Reauthorization did not resolve it. The returned error does not identify a rule. Source inspection at the matching tag shows that the flattened token scan associates the environment URL withStart-Process, and a dangerous classification withNeverleads toForbidden. This establishes the source-level false positive; the production binary was not instrumented to prove its internal call path.Proposed patch
Base:
rust-v0.153.4, commit3d2ee51ca2d5db578f328aa75e20aa22c0197c9a.Validation:
just test -p codex-shell-commandwith Rust 1.95.0 in a Linux container: 170 passed, 0 skipped. Three new tests cover 28 command strings, including unrelated environment/probe URLs, actual URL launches, dynamic launch targets, COM, stored scripts, quoted delimiters and parse failures.just fmtandgit diff --checkpassed. These are classifier tests on strings, not execution of the fixture commands or Windows desktop integration tests.This is a candidate for maintainer review, not a claim of comprehensive PowerShell safety verification. It has not been installed into the desktop executor. Please review the classification change and advise on an official release/update path for desktop users. An actionable denial reason identifying the heuristic would also help.
Full source diff follows (without local paths, raw logs, credentials or Git author metadata).
Candidate source patch and tests
andrew-adamson-proteros commentedon Sep 8, 2026
Additional reproduction on 8 September 2026: this false positive also occurs when no process-launch command exists at all. An ordinary string argument named
startis sufficient when an HTTP(S) URL appears in the same classified command. Even a single URL argument triggers rejection if its path or fully qualified domain name containsstart-processorinvoke-item.Minimal live reproductions (each submitted separately):
Codex rejects both before PowerShell executes. These arguments are literal output data; neither command requests a URL launch.
Environment and scope
pwsh.exeinstallation path.approval_policy = never,sandbox_mode = danger-full-access; filesystem access was unrestricted.exec_commandtool. They were not merely evaluated by a separately implemented classifier.example.invalidis used as inert data. No URL was opened, no network request was made by the test commands, and no actualStart-Processcommand was submitted.Live rejection and controls
The rejected calls returned an
exec_commandtool error with this structure, abbreviated to omit repetitive shell quoting and the local executable path:The rejection occurred before the submitted command executed. Successful controls exited with code 0 and printed the expected data.
1. A noncommand
startargument is enough.Rejected:
Both of these controls succeeded:
2. The same problem affects native-program arguments.
Rejected:
Replacing only
startwithrunsucceeded and printed['run', 'https://example.invalid/']:3. A here-string causes unrelated commands to become associated.
Rejected as a single
exec_commandinvocation:Changing the last argument to
runsucceeded. Keepingstartbut replacing the here-string URL withplain-dataalso succeeded.This version was likewise rejected:
However, these two ordinary commands succeeded together in one tool invocation:
This distinction matters: the problem is not simply that every script containing both strings is rejected. The restricted parser can preserve command boundaries for ordinary literal commands, while unsupported syntax such as here-strings sends the whole invocation through the fallback heuristic.
4. Additional token-matching controls.
Write-Output 'https://example.invalid/' 'START'Write-Output 'https://example.invalid/' 'prefix-start-process-suffix'Write-Output 'https://example.invalid/' 'restart'Write-Output 'https://example.invalid/'Write-Output 'start'5. Matching text inside the URL itself, including the FQDN.
Each row below was tested as its own
exec_commandcall usingWrite-Output '<URL>'. There was no separate launch-like argument or second command.Write-Outputhttps://example.invalid/starthttps://start.example.invalid/https://example.invalid/?action=starthttps://example.invalid/start-processhttps://example.invalid/invoke-itemhttps://start-process.example.invalid/https://invoke-item.example.invalid/https://prefix-start-process-suffix.example.invalid/https://prefix-invoke-item-suffix.example.invalid/https://ordinary.example.invalid/For example, this was rejected before execution:
These results distinguish whole-token matching for
startfrom substring matching forstart-processandinvoke-item. For the latter two, the URL token itself satisfies both the URL check and the launch-name substring check. This occurs even when the substring is embedded within a longer DNS label. No DNS lookup, network request, or browser launch is involved in printing these strings.6. HTTP, unusual URL spellings, and other URL-like strings with a separate
startargument.Each row below was tested separately using
Write-Output '<value>' 'start':http://example.invalid/HTTP://example.invalid/hTtPs://example.invalid/http:example.invalidhttps:example.invalidhttp:/example.invalidhttps:///example.invalid/prefix-http://example.invalid/http:////example.invalid/www.example.invalidexample.invalidftp://example.invalid/file:///example.invalid/ws://example.invalid/mailto:test@example.invalidhttps%3A%2F%2Fexample.invalidhttps ://example.invalid/httpx://example.invalid/http://.An additional control,
Write-Output 'http://.' 'run', succeeded. Thus an especially short reproduction is:These results are consistent with
looks_like_url()in the inspected Windows classifier: it searches case-insensitively for embeddedhttp://orhttps://prefixes, passes the resulting candidate (or the original token when no prefix is found) tourl::Url::parse, and accepts thehttpandhttpsschemes. Consequently, some nonstandard-looking slash forms andhttp://.qualify, while the tested scheme-less, encoded, and other-scheme strings do not. The matching is a syntactic classification; it does not require DNS resolution or a reachable server.Across all live variations above, there were 46 calls: 22 rejected calls and 24 successful controls. Every rejected call returned the same generic pre-execution policy error; successful calls printed the expected data and exited with code 0. This is a bounded reproduction set, not an exhaustive syntax matrix.
Current upstream source and release status
Source inspection was performed on 8 September 2026, approximately 13:28 AWST (UTC+08:00).
mainat95327467c3af9533ac25b171b3496b951fe425ed, committed on 8 September 2026 at 13:12:10 AWST.rust-v0.153.4, published on 5 September 2026 at 07:25:48 AWST.windows_dangerous_commands.rsandpowershell_tree_sitter.rsfiles were identical between that release and the inspectedmaincommit. The defect remains present in both source versions; I did not separately run the released 0.153.4 binary.The source explains the related failure modes:
is_dangerous_powershell_words()checks for a URL anywhere inwordsand independently searches all words forstart,start-process,saps,invoke-item, orii. It also accepts substrings containingstart-processorinvoke-item. It does not require the matching word to occupy the command position. This affects even successfully lowered commands such asWrite-Output ... startandpython ... start ....parse_powershell_command_into_plain_commands()delegates to the restricted Tree-sitter lowerer. The here-string fixtures explicitly expectnull. When lowering returnsNone,commands_for_exec_policy_for_platform()retains the whole shell invocation, andparse_powershell_invocation()in the Windows dangerous-command module usesshlexto flatten the script. An unrelated URL andstartargument can then be associated across commands.is_dangerous_powershell_words()predicate includest.contains("start-process")andt.contains("invoke-item"). A single argument such ashttps://start-process.example.invalid/therefore supplies bothhas_urland the substring match. Associating URLs with individual commands alone would not resolve this case: the classifier also needs to distinguish the invoked command from literal argument contents.In
exec_policy.rs,render_decision_for_unmatched_command_for_platform()maps a dangerous-command match toForbiddenwhen approval policy isNever.DangerousCommandMatch::Otherbecomes the generic reasonblocked by policy.tools/orchestrator.rsreturnsToolError::Rejectedfor that forbidden requirement before running the command.Separate source-level reproduction
In addition to the live tool calls, I compiled a small standalone Rust harness using the unchanged parser and Windows classifier files fetched from the pinned upstream commit. The harness only classified strings; it did not execute them.
It produced:
The last row classified
Start-Process https://example.invalid/as a string-only positive control. That command was not executed.Related PRs checked
I found no open or merged PR addressing this exact URL-plus-noncommand-
startcase in the searches and relevant file history inspected. This is a search result, not a guarantee that no unindexed or differently described work exists.These merged PRs are related but do not fix it:
Expected behaviour
Literal output data and native-program arguments named
startshould not be interpreted as PowerShell launch commands. Neither should URL paths or hostnames containingstart-processorinvoke-item. A fix should address both command-position recognition and URL ownership within the relevant command expression. Existing protection for actual URL/ShellExecute launches should remain intact.Regression coverage should include ordinary
startarguments, single URL arguments containing the longer substrings in their path or FQDN, the here-string cross-command case, and an actual URL-launch classifier control. HTTP and parser-accepted unusual forms such ashttp://.also reproduce the false positive. The successful URL-with-start, encoded/other-scheme, and ordinary separate-command controls above help preserve the distinctions already handled correctly.bstisgood commentedon Sep 9, 2026
Additional sanitized Windows Desktop occurrence, observed on 2026-09-08.
OpenAI.Codex 26.901.6511.0.resolvedApprovalPolicy=never; this is not a claim that every effective policy source has been identified.--package-lock-onlyand--ignore-scripts, not deployment or execution of package lifecycle scripts.The compound PowerShell invocation constructed a
System.Diagnostics.ProcessStartInfowithUseShellExecute=falseand contained an HTTPS npm registry argument. The URL was package-manager configuration, not a request to open a URL via ShellExecute.The tool immediately returned a
CreateProcessrejection ending inblocked by policy, with reported wall time 0.0 seconds. No npm output or lock file was produced. The command was not rerouted through CMD or another execution tool, and no permission rules were changed.The public
is_dangerous_powershell_wordsimplementation checks for a URL alongside a token containingshellexecute. That makes this command shape consistent with the heuristic discussed here, including the literalUseShellExecute=falsecase. However, the denying rule and the installed desktop engine's exact source revision have not been established; this is a suspected relationship, not a confirmed diagnosis or a separately executed minimal reproduction.The user has already uploaded in-app feedback and explicitly authorized sharing its ID here:
01a005b9-7b99-77d3-b70c-d385c882ddd4Could maintainers confirm whether this is the same classification issue and identify a supported, narrowly scoped resolution or diagnostic path? Protection against actual unsafe URL/ShellExecute launches should remain intact.
No project source, personal filesystem paths, credentials, raw logs, or full conversation are included in this comment.
staminaoo commentedon Sep 9, 2026
Additional Windows desktop occurrence observed on 2026-09-09, with a variation: the unrelated loopback URL was only a value printed in the final result object. It was neither a process argument nor a health-check request.
Environment and actual observation
codex-cli 0.153.4.approval_policy=Neverandsandbox_policy=DangerFullAccess; configuration also hadapprovals_reviewer="user".127.0.0.1.One compound PowerShell tool invocation attempted a local
Start-Process -WindowStyle Hiddenlaunch with redirected logs, then printed the process ID and preview URL. It was rejected before execution:Abbreviated, redacted shape of that recorded invocation (not an independently executed minimal reproduction; directory setup, log redirection and PID-file output are omitted):
Read-only inspection of the original command confirmed that its URL appeared only in the final display statement, not in the launch statement. A subsequent foreground preview launch succeeded. The rejected background invocation was not replayed, and no permission or execution-policy rules were changed.
Source correlation and requested improvement
The 0.153.4 classifier checks for a URL and launch-related words across the supplied token list. The execution-policy code maps a dangerous match plus
NevertoForbidden. This is consistent with the observed failure, but the generic error did not expose an actual matched-rule/classifier trace.Please include an unrelated printed URL/result-object value in regression coverage, provide an actionable rejection reason, and clarify the Full Access UI wording. The current wording led me to expect this authorized local development operation to run without approval, making the unexplained denial particularly confusing. Existing protection for actual unsafe URL/ShellExecute launches should remain intact.
No private project paths, public-facing personal domains, credentials, screenshots, or raw diagnostic logs are included.
Josh-Gamer commentedon Sep 10, 2026
Additional sanitized Windows Desktop occurrence on 2026-09-10: the noncommand
starttoken was inside Python source being generated within a single-quoted PowerShell here-string. This extends the literal-data case described above.Environment and observed failure
OpenAI.Codex 26.903.9818.0.26.903.71938.0.153.4; the running desktop executor path was the npm-installed native CLI.approval_policy=never,approvals_reviewer=user, andsandbox_policy=danger-full-access.The authorized operation was creation of one local unit-test file. A PowerShell here-string held a Python file-generation program; that program contained the test source as a triple-single-quoted string. The test source included a Python variable named
startand synthetic HTTPS Origin values. The operation did not request a browser or URL/ShellExecute launch.The tool rejected the command before process creation:
The target file remained absent. An identical resubmission after a normal desktop restart was also rejected. Static parsing of the complete original PowerShell command reported zero errors.
Independently verified classifier-only example
The following synthetic example was passed only as data to a standalone classifier, not submitted to the desktop execution tool or executed as PowerShell/Python. It contains no project source, filesystem paths, or network operation:
A small Rust harness included the unchanged upstream Windows classifier at commit
94697375cb9d2aa8ae74d61957c6b396819bec94. The source Git blob was verified ascc1ae671c831130dd33d11bac690d3052430b6dd. The harness read stdin intoscriptand called:Built successfully with
cargo build --offlineusing existing cached dependencies: shlex 1.3.0, once_cell 1.21.3, regex 1.12.2, and url 2.3.1. These are the reproduction's dependency versions, not a claim of exact dependency equivalence with the installed executor.Result for the synthetic example:
The same standalone classifier also returned
truefor the byte-verified original command. Neither classifier run executed its input or modified the target file.Diagnostic limits and requested improvement
A same-version
execpolicy checkagainst the user's rule file returnedmatchedRules: []; that tests the supplied rules, not the full runtime fallback. Local DEBUG/TRACE records showed only Allow prefix rules being loaded. For the rejected call, the available log contained the generic router error without the matched classifier or decision inputs.This strongly supports the literal-data false positive, but the exact in-process branch taken by the running executor remains unconfirmed. The independent harness tests the Windows classifier; it does not reproduce the complete desktop parser/policy pipeline.
Please include nested Python source strings in regression coverage, distinguish actual PowerShell command positions from literal argument/string contents, and preserve a specific rejection reason through the classifier and policy layers. Existing checks for real URL/ShellExecute launches and unresolved dynamic execution should remain effective. Safe diagnostic fields such as parser path, classifier reason, effective approval mode, and final decision would make these failures actionable.
This comment omits local usernames, repository identifiers, absolute paths, task/call IDs, credentials, project source, and raw logs.
JosephFrancisRe commentedon Sep 12, 2026
Additional Windows desktop occurrence: Unity configuration rejected before execution
Prepared 2026-09-12 UTC for user-authorized public submission. This is a sanitized
diagnostic report, not a workaround script. No credentials, tokens, private account
identifiers, live service address, raw conversation, or private repository URL are
included.
This appears related to #40060: the rejected PowerShell invocation contains
Start-Processand an HTTPS URL. In this occurrence the URL is a configurationargument to an explicitly named local Unity executable, not the launch target or
a request to open a browser. The actual denying classifier in the installed
executor has not been identified; this is a suspected relationship, not a proven
root cause or a separately tested minimal reproduction.
The owner reports submitting two in-app feedback reports. Their feedback IDs have
not been provided, so no session or feedback identifier is included here.
Problem and impact
A user-authorized Unity Editor configuration operation is rejected by the Codex
execution tool before the outer PowerShell process starts. The user selected Full
Access and restarted the desktop app. One normal retry after restart returned the
same rejection. Ordinary read-only PowerShell and Git diagnostic commands continue
to work. The project-to-development-service connection remains unconfigured.
The returned error has this shape (workstation paths and command body omitted):
No rejecting rule ID, rationale, approval prompt, Windows error code, or remediation
is returned. No sandbox-permission override was requested on the failed call.
Environment
codex doctor: 0.153.4.and enabled network access.
official distribution checks did not provide an installable newer package.
No downgrade, forced update, or reinstall was performed.
Rejected operation: scope and arguments
The outer PowerShell script checks that no Unity process is running, creates an
ignored log directory, launches the existing pinned Unity executable with
Start-Process -WindowStyle Hidden -PassThru, waits for exit, and checks a fixedsuccess marker. Project and log arguments containing spaces are explicitly quoted.
The argument structure below is descriptive; placeholders are not runnable paths:
The inspected Editor method validates the origin locally and saves only the public
endpoint field of the existing settings asset through Unity's AssetDatabase APIs.
It does not read a credential vault, sign in, call an account/cloud API, enable a
server feature, or grant rewards. Normal Unity imports/cache writes may occur.
The isolated feature worktree was clean and no Unity process was running.
Correlated evidence
All timestamps below are UTC on 2026-09-12.
Codex CLI initialized.next=connected,initialized=true,connectionError=null.responseActivePermissionProfile=:danger-full-access,responseApprovalPolicy=never, andresponseSandboxPolicy.type=dangerFullAccess.resolvedApprovalPolicy=never,resolvedApprovalsReviewer=user.The resume log also contains derived defaults of on-request/workspace-write, but
its returned active settings and subsequent turn-start settings say never/Full
Access. The default fields alone are not evidence that the task lost Full Access.
Successful Unity logs contain:
Earlier successful commands also use
-batchmode, synchronous-executeMethod,-quit, and quoted spaced paths. They are comparison evidence, not an identicalconfiguration reproduction. Mocked test success is not live server verification.
Diagnostics performed and limits
codex doctor --json: installation/configuration consistent, app-serverinitialized, provider HTTP/WebSocket reachable, databases inspectable, and no
locally visible recent Codex security enforcement found.
TERM=dumbcheck. Its standaloneCLI on-disk sandbox defaults are not the active desktop task's permissions.
no matching explanation was found. Inspected runtime log-database metadata for
this task and threadless entries during 02:17-02:25; no
blocked by policyrecord was found. Database access was read-only; no conversation or reviewer
reasoning was exported.
Queries for warning/error events during 02:17-02:21 returned no matches. This
does not prove that every possible Windows/security control was ruled out.
matching rule. It does not prove all host-side/managed controls allow the action.
after-agent notification hook's Windows error 206 at turn end. Neither identifies
the launch denial. No hook, Defender exclusion, permission, or policy was changed.
blank and retains its pre-attempt modification timestamp.
Diagnosis and requested resolution
Confirmed failure boundary: command execution is refused before PowerShell/Unity,
while the desktop records Full Access for the task. The exact rejecting component
and rule remain unidentified. This is not evidence of an AWS IAM failure, a Unity
compile error, or a particular known app bug.
Please identify which execution/approval layer emitted
blocked by policy, explainwhy no rationale or rule identifier reached the tool result, and provide the
supported remedy or exact-action approval procedure for this desktop version.
If a newer build fixes this case, please confirm its accessible Windows update
channel rather than relying only on advertised version metadata.
No retries after the post-restart denial, alternate execution routes, security
weakening, cloud changes, game-credential use, or destructive fallback were attempted
during this investigation. Existing application work and user edits are preserved.
Official diagnostic references
Only sanitized excerpts are included. The original conversation and raw logs have
not been attached to this public report.
reneehuang92 commentedon Sep 12, 2026
Additional Windows desktop occurrence observed on 2026-09-12, submitted at the account holder's explicit request.
The rejected command contains
Invoke-RestMethodagainst a loopback status endpoint and a separateStart-Processlaunching a local PowerShell service-restart script in the same tool invocation. The URL is not a launch target or an argument toStart-Process. This closely matches the command shape reported here, but we have not established the effective denying classifier in our installed desktop build.Environment and result
OpenAI.Codex 26.903.9818.0. The bundled engine version was not independently queried for this report.danger-full-access,approval_policy=never, and network access enabled.CreateProcess ... rejected: blocked by policy, before execution.Scope and impact
The user-authorized operation was to validate graceful shutdown and restart of an already repaired local Python service. The existing restart script checks that automated trading is OFF and verifies the current process identity. Restart would close an existing brokerage session and establish a new authenticated session; it is not purely read-only. It would not place, cancel, or amend orders or enable trading.
The rejected invocation never ran. A subsequent independent status read confirmed the already-running service remained OFF, connected, and reconciled. We have not retried that denied restart through another wrapper/client, split the operation to evade rejection, or changed security settings. Matching this issue's command shape is evidence for investigation, not proof that our entire service operation should be permitted.
The account holder reports approximately a week of development usage and repeated launch/validation interruptions. Earlier product Feedback was successfully submitted on September 11, but no actionable response or human case number has been obtained:
no-active-thread-01a08e1d-22c6-7383-aee3-64dd5eec487bQuestions for maintainers
Start-Process/ unrelated-URL classifier still present in this desktop package? Is there a fixed Windows desktop build and an accessible official update channel?/approveflow explicitly describes the open-source TUI; we cannot confirm it applies here.No credentials, email address, brokerage account identity, private project paths, raw sessions, or brokerage logs are included. We are requesting an actionable diagnosis and supported resolution, not a security bypass.
15 remaining items
aiyang-bai commentedon Oct 6, 2026
Additional 0.160.0 Windows Desktop occurrence with a preserved original call and local source-only reproduction. Posting with the affected user's explicit authorization. This is intended as new evidence for this existing issue, not a duplicate report.
Environment and incident policy
26.930.41038, build1302226.930.4958.00.160.00.160.07.6.5approval_policy=neversandbox_policy.type=danger-full-accesspermission_profile.type=disabledTherefore, for this occurrence, "Full Access was not actually enabled" does not explain the rejection.
Incident time:
2026-10-05T17:40:26.619ZTool call ID:
call_2IJcdQLLtM4BcemfNh6sUrbHThe returned error was the same family:
The rejection occurred before the bundled
pwsh.exewas created; the local Helper did not start. No retry or alternate launch path was used.Original command structure
The exact original command was recovered locally and preserved privately. It is not pasted here because it contains private filesystem details.
Native PowerShell AST parsing reports no syntax errors and shows two distinct invocations:
The URL belongs to the independent loopback health request. It is not the
Start-Processtarget.Pinned 0.160.0 source reproduction
I pinned the public
rust-v0.160.0source to commita956835d020762cb2b570053af06f643a11c0eccand used the unmodified Windows classifier:https://github.com/openai/codex/blob/a956835d020762cb2b570053af06f643a11c0ecc/codex-rs/shell-command/src/command_safety/windows_dangerous_commands.rs
The relevant logic computes
has_urlacross the whole flattened PowerShell token list, then independently searches that same list forStart-Process/ launch tokens.Using the preserved original argv as classifier input only (the command was not executed), the 0.160.0 classifier returns
dangerous=true.A simplified string-only diagnostic reproduces the same false positive:
Diagnostics:
Invoke-ItemURL: dangerousAll of the above were classifier/string tests only. None of the dangerous commands were executed.
I also compared the 0.160.1 Windows classifier bytes available locally; they are identical to 0.160.0 for this file, so I do not have evidence that 0.160.1 fixes this issue.
Attribution limit
This establishes that the same-version public classifier has a false-positive path matching the preserved command shape. It does not prove that the original installed call selected this exact internal branch: the original per-call matched rule/category/fallback was not exported.
So the current conclusion is deliberately limited to:
Maintainer request
Could maintainers please:
blocked by policy.No credentials, real private paths, raw logs, complete command, conversation transcript, or business data are included here. No production/business code or local host policy was modified.
Related diagnostic-explanation issue: #49373.
Jonathan-Ironman commentedon Oct 6, 2026
Still occurs on codex-cli 0.160.1 on Windows with Full Access.
This also affects
startused as a subcommand of an unrelated CLI, not justStart-Process.Observed runtime settings in the local Codex logs:
The command had this shape (CLI name and task text anonymized):
Codex rejected the command before PowerShell or the target CLI ran:
This is a CLI subcommand with a URL in a text argument. It does not invoke the PowerShell
startalias or request a browser launch. The rejection occurred repeatedly, including after the user explicitly authorized the operation. Local user execpolicy rules had no matching prohibition.The shipped version's classifier explains this case:
https://github.com/openai/codex/blob/rust-v0.160.1/codex-rs/shell-command/src/command_safety/windows_dangerous_commands.rs
is_dangerous_powershell_wordscomputeshas_urlacross all arguments and matches any token equal tostart. It does not check whetherstartis the command being executed.looks_like_urlalso searches for URL prefixes inside text arguments.Please add a regression case for
startas a CLI subcommand with a URL in a quoted data argument. The classifier should associate command identity and URL arguments with the relevant PowerShell invocation. The rejection should also identify the matched rule instead of returning onlyblocked by policy.lovekkcoola-glitch commentedon Oct 8, 2026
Additional Windows Desktop evidence: a rejected command did not contain any PowerShell process-launch command.
Environment: Windows 11 Pro x64, OS 10.0.26200; PowerShell 7.6.5; Desktop package 26.1002.7124.0 (internal app 26.1002.52244, build 13536); the running bundled core was previously identified as 0.162.0-alpha.2. At the time of these rejections, the effective tool context was approval policy
neverand sandboxdanger-full-access.Two actual tool requests were rejected before execution: a readiness/report request on October 8 and a read-only HTTPS diagnostic request on October 9 (Asia/Shanghai). Both returned
CreateProcesswrappingRejected/rejected: blocked by policy. The new diagnostic did not execute or create its intended receipt.For each original request, I parsed the exact submitted command string with the PowerShell Parser without executing it. Both parsed with zero errors; the only PowerShell command node was
python. The script was passed through one single-quoted here-string. The here-string data contained URLs and the ordinary wordstart; the new request included the descriptionno process start or rejected action retry. There was no actualStart-Process,Invoke-Item, orstartcommand node.The corresponding public source at commit
74e804deeb1241d5fe699b31fb319f7d46454c42usesshlex::spliton the complete PowerShell-Commandbody and scans the flattened words for a URL plus a launch-related word:https://github.com/openai/codex/blob/74e804deeb1241d5fe699b31fb319f7d46454c42/codex-rs/shell-command/src/command_safety/windows_dangerous_commands.rs
A Python POSIX-shlex approximation of the original strings produces an exact
starttoken plus URL tokens in both cases. This is supporting static evidence only: I have not run the Rust classifier, and the tool error and available logs do not expose the matched rule or classification. I cannot prove the runtime branch from that output alone.Could maintainers check whether inert here-string data is being classified as a launch command, and provide the specific rejection rule in diagnostics? Any classifier correction should preserve rejection/review of real URL-launch commands.
The affected Desktop chat has no permissions control according to the user's repeated UI checks, and the app updater reports
up_to_date. After these rejections, a separate local collaborator changed the user configuration default toon-request; the current turn still declaresnever, so active-chat adoption has not been verified. The blocked requests were not rewritten, split, or rerun through another executor; no installed-core changes were made. No post-configuration-change retry is included in this report. This report contains no credentials, business data, raw logs, or private filesystem paths.ruekenndesiraeinghalry-spec commentedon Oct 9, 2026
补充一个 Windows Codex Desktop 实例，疑似相关，但尚未确认共同根因。
环境：Windows 11；桌面包
26.1002.7124.0；运行 CLI0.162.0-alpha.2。拒绝时为danger-full-access、approval_policy=never。用户已授权更新一个本机 Node 后台。原 PowerShell 命令先通过回环 HTTP 核验任务状态，再核对目标 PID、程序路径和端口，随后停止并启动同一程序。HTTP 地址属于状态查询，不是进程启动参数。
最新拒绝时间：2026-10-09 15:15:49.968 UTC+08:00。内部调用号：
exec-d35b4d8f-cd3b-4a23-9d01-1898629b2f6d。返回
exec_command failed: CreateProcess … rejected: blocked by policy，命令未启动。原命令对已检查本地规则的只读检查返回matchedRules: []；这不排除内置或其他策略。旧服务和结果文件保持不变。请维护方确认：具体由哪个判断及命令片段触发？是否属于本问题？当前版本支持哪种针对该操作的审批或恢复路径，是否已有修复版本？
本文不附账号、私有源码、账本、完整命令或原始日志；如需进一步证据，请指定最小范围和私密提交渠道。
XianBeiQiShi commentedon Oct 10, 2026
Additional source-level verification of this false positive.
I compiled the unchanged upstream
windows_dangerous_commands.rsinto an isolated Rust harness and supplied command strings strictly as data:truefalsefalsetrueThe URL in the combined script belonged to the status check, not to
Start-Process.These are direct classifier tests: the fixture commands were not executed, and the harness does not reproduce the complete exec-policy pipeline. The results reproduce the cross-command association in
is_dangerous_powershell_words.There was also a related pre-execution rejection while generating a diagnostic report. The submitted command contained
Start-Processas prose inside the report text, alongside HTTP URLs; it did not invokeStart-Process. The tool returned:The exact internal decision path of that running executor was not instrumented. Its behavior is consistent with the flattened-token fallback, and suggests regression coverage should include quoted report content containing launch keywords and unrelated URLs.
Please consider command-scoped URL matching and a rejection message identifying the matched heuristic. Protections for actual URL-launch operations should remain intact.
dhanur2 commentedon Oct 12, 2026
Reproduced with
codex-cli 0.162.0-alpha.17.2on Windows PowerShell. This needs no process launch, file write, credential, scraper, or network request. It is an output-only here-string:Actual result from
exec_command: rejected before process creation withCreateProcess ... rejected: blocked by policy.Controls submitted independently:
throw new Error('Existing start receipt: resume only');passed with exit 0 and printed that line.const profileURL='https://example.invalid/diagnostic';passed with exit 0 and printed that line.The JavaScript is literal PowerShell string data; it is never evaluated. The reserved
example.invalidURL is never accessed. The combined request never produces a process ID or an application result.The exact-release Windows classifier scans best-effort flattened shlex tokens for
starttogether with a URL, rather than distinguishing PowerShell here-string data from a ShellExecute invocation. The execution policy converts dangerous matches to Forbidden under approval policy Never and supplies this generic message.Please distinguish literal here-string/source data from actual URL-launch commands and expose the specific classifier/rule in rejection diagnostics. Actual dangerous URL launches should retain their existing checks. No policy override or alternate execution route was used to perform the originally denied operation.
justinthevoid commentedon Oct 14, 2026
Additional reproduction on the Windows Desktop command runtime
codex-cli 0.162.0-alpha.17.2(Desktop26.1007.71326, Windows 11 Pro build 26300, PowerShell7.7.0-preview.5). The affected chat's retained effective settings were Full Access /approval_policy=never, rather than merely defaults in config.toml.One useful extension to this report: the launch cmdlet need not be invoked at all. Its name can be inert search data:
This is a read-only HTTP fetch and text search, with no process launch. This exact script shape was tested as command data against the unchanged Windows classifier from the official matching runtime tag: the new “should not be dangerous” assertion fails. A second assertion using a loopback health request followed by a separate local executable launch also fails; all 40 existing Windows-classifier tests pass.
A corresponding public-source diagnostic invocation was rejected by Desktop before PowerShell started, with only:
Root cause in the matching version:
Please cover both inert launch-name arguments and unrelated commands in a regression fix, while retaining conservative handling of actual URL launches and dynamic execution. A more specific rejection reason would also help distinguish this pre-review checker from an Auto-review/Guardian denial.
No private project paths, prompts, credentials or raw session logs are included. No policy-enforcement runtime was replaced.
MorrisYUJQ commentedon Oct 15, 2026
Windows Desktop 补充报告：请确认 PR #54076 的桌面发布版本及不降低保护的恢复路径
用户已明确授权提交以下脱敏诊断摘要，不共享完整会话或原始日志。
环境
故障现象
用户授权启动一个现有本地桌面工具，用于只读访问其指定的群聊记录。一次 PowerShell 请求组合了本地程序启动和独立的 loopback HTTP 健康检查，在 CreateProcess 前立即返回 blocked by policy，没有程序输出或退出码。
历史上同一工具可以正常运行，当时启动和健康检查是不同调用。本次拒绝后没有通过拆分、改写或包装同一操作来重试，也没有更改权限、安全设置或允许规则。其他普通只读诊断可执行；没有证据表明已运行到本地工具的兼容性、登录或插件加载阶段。
本机尚未取得具体命中规则 ID，因此这里报告的是与 #40060 高度吻合的症状和源码线索，不是已捕获内部执行追踪的结论。另见相同内置版本的相关报告 #53977。
已核对的修复与发布状态
官方 PR #54076 已在 2026-10-14T19:48:07Z 合并，commit 为 80b88a7。
#54076
实际读取公开发布列表与相关文件后：稳定 0.162.1 仍有旧判断；预发布 0.163.0-alpha.10.1 和 0.163.0-alpha.11 均未包含 powershell_commands_are_independent 改动，两者该文件 blob 均为 cc1ae671c831130dd33d11bac690d3052430b6dd。没有安装这些版本，也没有替换 Desktop 的内置执行器。
原请求包含普通管道；#54076 对管道、脚本状态等仍保留保守回退。因此不能仅凭该 PR 已合并就保证原请求已经被修复。
希望官方明确答复
本评论仅含脱敏环境信息、故障摘要和公开源码引用。未附群聊正文、群名/群号、个人路径、账号凭据、照片或完整会话。
usofm commentedon Oct 15, 2026
Additional Windows desktop occurrence; possible relation to this issue, with the common root cause still unconfirmed.
Observed incident
On 2026-10-14 at 21:24:37 UTC, an explicitly authorized request to start two isolated local development services was rejected before PowerShell/process creation with:
exec_command failed: CreateProcess ... Rejected(... rejected: blocked by policy)Both
Start-Processcalls targeted local executables and specified-WindowStyle Hidden. The same script contained loopback HTTP-origin configuration; the URLs were not passed as browser/URL-launch targets. The intended listeners were loopback-only. This is a historical observed workflow, not a newly executed minimal reproducer.The retained effective turn context recorded:
approval_policy=neverapprovals_reviewer=usersandbox_policy.type=danger-full-accesspermission_profile.type=disabledThis establishes a pre-execution policy refusal, not a verified Auto-review/Guardian decision.
Bounded diagnostics
codex-cli 0.162.1; the exact embedded executor version at the original incident was not independently captured.codex execpolicy check, supplied the original shell/command tokens as data and the existing userdefault.rules, returned exit 0 with{"matchedRules":[]}. This covers that file only, not every effective policy layer. The rejected command was not executed.codex doctor --jsontimed out after 45 seconds without producing a report.Clarification requested
PR #54076 is merged. Which supported Windows desktop release includes it, and how can affected users obtain an exact-action review or supported recovery when the interactive permission control is unavailable? Please also expose the rejecting rule/classifier or a minimal safe diagnostic to distinguish this case from other policy refusals.
No policy override, global security relaxation, alternate execution path, or startup retry was used after refusal. No private project source, directory paths, account/session identifiers, credentials, raw transcript, environment values, or application data are attached. Please consolidate this occurrence here rather than opening a duplicate issue.
usofm commentedon Oct 15, 2026
Follow-up to #40060 (comment), explicitly requested by the affected owner.
The desktop's built-in update check now confirms installed version
26.1007.71326, build20398, distributionprod, statusup_to_date. No eligible update is offered. We have not replaced the bundled executor, changed release channels or security settings, or retried the rejected startup.Could the team please clarify:
The original request contained script state; #54076 retains conservative handling of such cases. We therefore cannot assume the merged PR will resolve this particular incident. If confirmation requires diagnostics, please specify the minimal fields and an appropriate private submission route, without requiring a complete session transcript.
Only sanitized version information and the workflow purpose are shared here; no credentials, raw logs, session identifiers or application data are attached.
usofm commentedon Oct 15, 2026
Specific scope clarification requested by the affected owner, supplementing #40060 (comment):
May the human owner independently start the approved isolated local test services manually, using normal application procedures, while the Codex desktop agent does not execute, rewrite or delegate the rejected startup at all, and then limit the agent to ordinary browser testing and capturing real screenshots for the English/Arabic/Persian Control and Amer Service training guides?
Please confirm whether this separation is officially permitted for the reported pre-execution policy refusal, and identify any required supported review, conditions or approval. If it is not permitted or cannot be established from this public report, please say so and point to the appropriate official review channel. We are asking about the scope of the restriction, not treating manual execution as an assumed workaround.
The owner consents to this proposed separation and has requested official confirmation of its policy status. Owner consent is not being treated as an official answer or a policy override; we have not initiated the manual-start handoff or the subsequent browser/testing/capture workflow. Existing security settings and normal application authentication/authorization remain in place; no injected credentials, sessions, roles or licenses are proposed. No raw logs, private identifiers or application data are attached.
vjhlv commentedon Oct 16, 2026
Additional Windows Desktop occurrence; requesting a supported fix or exact-action review path.
The running bundled executor reports codex-cli 0.163.0-alpha.10.2. The desktop app's built-in updater reports installedVersion 26.1013.31256, installedBuildVersion 20586, installedReleaseChannel prod, status up_to_date.
A user-authorized local Python launch was rejected before process creation with CreateProcess / Rejected / rejected: blocked by policy. The PowerShell request contains a local Start-Process invocation, variables, and an unrelated HTTP mailbox configuration value. The URL is not the executable launch target. The request was retried unchanged after an official app update and received the same rejection.
Effective settings record full access, approval_policy=never, approvals_reviewer=user. The inspected local rules contain allow entries only. An offline check of that rule file reported no matches. These observations do not exclude built-in or managed policy. No exact internal classifier ID was exposed, so this occurrence is consistent with #40060 rather than a proven internal trace.
PR #54076 is merged, but its description retains conservative handling for script state and pipelines. Please confirm:
No installed executable, security configuration, or rule file has been modified. No alternate execution route was used to carry out the rejected operation. This report contains no account identifiers, credentials, local paths, task/session IDs, raw logs, or conversation transcripts.
eimhenry-dt commentedon Oct 16, 2026
Could the team clarify the supported Windows Desktop distribution and scope of merged PR #54076?
The PR description says that independently parsed literal PowerShell commands are classified separately, while pipelines and script state retain conservative checks.
This asks for an official fix/review path, not a policy bypass, blanket allow rule, or replacement executor.
Public reference: #54076
usofm commentedon Oct 16, 2026
Owner-requested update to our occurrence and pending scope question: #40060 (comment)
After the normal app restart, the running desktop's built-in updater confirms:
26.1013.31256, build20586, distributionprod, statusup_to_date(verified 2026-10-16 at 07:45 UTC).codex-cli 0.163.0-alpha.10.2via--version.The official source for that exact runtime tag still passes flattened PowerShell tokens to the URL/launch-name matcher. This source observation is not a full binary attestation, an internal decision trace, or a claim that the original incident has been resolved. We have not retried the rejected startup after updating.
Could the team explicitly confirm whether the owner may independently start the isolated local test services manually through normal application procedures, while the agent performs no startup/rewrite/delegation and subsequently only drives the browser and captures real application screenshots for Control and Amer Service EN/AR/FA training? Please state any supported review prerequisites or conditions, or confirm that this route must remain on hold and identify the appropriate official review channel.
The owner has expressly requested no action on this route before an applicable official answer. We have not initiated a manual-start handoff, supplied manual-start instructions or begun the dependent browser/testing/capture workflow. Security settings and normal application authentication/authorization remain unchanged. No credentials, private identifiers, raw logs or application data are attached.
drwbkr1 commentedon Oct 16, 2026
After an official update and restart, Windows Desktop reports
26.1007.71326, build20398. Its signed bundled executor reports0.162.0-alpha.17.2; the running and bundled copies match.Does this Desktop build include PR #54076, commit
80b88a7? Does that fix cover environment-variable assignments containing an unrelated URL alongside Node/Next’sstartargument? If not, which supported Desktop build does, and what minimal diagnostic identifies the original rejecting policy?No security settings, executables, or rules were modified. The rejected startup has not been retried.