[Windows Codex Desktop] Service restart rejected as “blocked by policy” despite user reviewer and full filesystem access

What issue are you seeing?

Codex Desktop on Windows is rejecting an ordinary local service/application restart before the command executes, even though the effective settings show:

• approval reviewer: user
• filesystem access: full / unrestricted
• the applicable local cleanup/project rule does not prohibit starting or restarting services

The only runtime result surfaced to the agent/user is:

blocked by policy

The agent inspected the effective settings and rejection record and could not identify any documented setting that explains the denial. This creates a dead end: the user has already selected the permissive reviewer and full filesystem access, yet Codex still cannot perform the local operation and cannot say which rule rejected it.

Why this appears to be a product bug

The visible/effective configuration and the runtime decision contradict each other from the user's perspective:

1. The configured approval reviewer is the user.
2. The task has full filesystem access.
3. The requested action is a local service/application restart, not a deletion or broad destructive operation.
4. The local project/cleanup instructions do not forbid service startup.
5. The restart is rejected before execution with only blocked by policy.
6. No policy rule ID, classifier, matched command fragment, or recoverable approval path is exposed.

This is distinct from reports about exact file deletion and the known PowerShell URL/Start-Process classifier false positive. The common symptom is the same opaque pre-execution blocked by policy result.

Expected behavior

For a benign local restart under user-selected approval review and full filesystem access, Codex should do one of the following:

1. Execute the command.
2. Ask the user for an explicit one-time approval if a separate protected-operation rule applies.
3. Return a concrete policy identifier and matched reason that explains why the operation is forbidden and what supported setting, if any, controls it.

It should not silently override the visible permission model with an unexplained hard block.

Diagnostic request

Please expose enough information to make these failures diagnosable:

• policy/rule identifier responsible for blocked by policy
• whether the block came from execpolicy, automatic approval review, Desktop host policy, or another hidden layer
• the matched command/operator or protected action category
• whether the decision is configurable by the user
• a correlation/request ID that support can use to inspect the backend decision

A reproducible harness diagnostic would also be useful: given a candidate command plus the effective sandbox/reviewer configuration, show the policy decision without executing the command.

Environment

• Platform: Windows
• Client: Codex Desktop
• Same-day Codex Desktop rollout on this machine reports bundled CLI 0.153.3; the exact affected task's app package version was not surfaced in the screenshot and can be supplied separately if needed.
• The affected task reported full filesystem access and the user as approval reviewer.

Impact

This blocks ordinary local development/automation work after the user has already granted the permissions the product exposes. More seriously, the product cannot explain which rule remains in force, so the user is pushed into repeatedly changing settings without evidence. This materially undermines trust in the permission/approval model.

Related reports

• #38886 — exact user-authorized file deletion blocked before PowerShell starts
• #40060 — Windows execpolicy false positive involving Start-Process and an unrelated URL

This report is intentionally separate because the affected operation is a service/application restart and the core problem is the contradiction between the effective user-selected reviewer/full-access state and an opaque hidden policy rejection.

Reproduce the restart rejection on Windows Codex Desktop with the reported full filesystem access and user reviewer settings, using the bundled CLI 0.153.3 context where applicable. Trace the rejection record to identify the responsible policy layer and expose a rule identifier, matched reason, and supported approval path; done when a benign restart executes, prompts appropriately, or returns an actionable explanation.