Windows Codex App still asks for approval even with approval_policy=never and danger-full-access

Root cause analysis

I traced two distinct issues that together explain the behavior.

Finding 1: --session-source defaults to "vscode" in app-server

File: codex-rs/app-server/src/main.rs (~line 35)

#[arg(
    long = "session-source",
    default_value = "vscode",   // ← hardcoded default
    value_parser = SessionSource::from_startup_arg
)]
session_source: SessionSource,

The SessionSource::VSCode is also the #[default] variant in codex-rs/protocol/src/protocol.rs. This explains why the rollout JSONL shows "source": "vscode" — the Windows Desktop app launches the same app-server binary used by the VS Code extension, and if --session-source is not explicitly passed, the default is always "vscode". This is a logging/diagnostic issue but not itself the cause of the approval prompts.

Finding 2: Likely cause — Constrained<AskForApproval> silently overriding never

In codex-rs/core/src/config/mod.rs (~line 3296), there is a config-requirements validation that can silently reject approval_policy=never:

"`approval_policy = \"never\"` cannot be used because requirements do not allow `sandbox_mode = \"danger-full-access\"`"

If managed config requirements (e.g. from MDM or cloud policy) restrict approval_policy to on-request, then the session's Constrained<AskForApproval> field silently falls back to on-request even though the JSONL metadata records the requested value "never". The metadata reflects what was asked for, not necessarily what was enforced.

Finding 3: Windows-specific path in exec_policy

File: codex-rs/core/src/exec_policy.rs (~line 653)

let environment_lacks_sandbox_protections = cfg!(windows)
    && profile_is_managed_read_only(permission_profile, ...);

With danger-full-access (PermissionProfile::Disabled), profile_is_managed_read_only() returns false, so this path should NOT be triggered. But it is worth confirming the PermissionProfile value is correctly propagated to the exec policy evaluation.

Suggested investigation path

1. Check whether any managed config requirements (MDM, cloud policy, TOML config layers) constrain approval_policy — if so, the Constrained wrapper would silently reject never while the JSONL still shows "never" as the requested policy
2. Add a log line at the Constrained::set call site for approval_policy to surface silent fallbacks
3. The Windows Desktop app launcher should pass --session-source desktop (or a new SessionSource::Desktop variant) to improve diagnostic accuracy

Happy to contribute further analysis or a fix if the team would like to invite a PR.

I can reproduce the same class on Windows Desktop: the visible per-chat mode is Full Access, but worker chats still transition to a waiting-for-approval state for routine local actions.

Observed impact:

• orchestration/quality/support worker chats stop instead of continuing their assigned local work;
• recreating or restarting a chat does not reliably preserve the intended no-approval behavior;
• this makes unattended local development unreliable even when Full Access has been deliberately selected.

Expected behavior:

• when the effective thread context is Full Access / no-approval, routine local shell and workspace actions should run without a new manual prompt;
• if an action is intentionally excluded, the UI should show the effective policy and the specific reason before the worker is paused;
• a newly created replacement thread should inherit the selected permission mode consistently.

No repository paths, source content, credentials, user data, or external endpoints are included.

I encountered what appears to be the same issue on Codex Desktop for Windows.

Environment

• OS: Microsoft Windows 11 Home 25H2, version 10.0.26200, build 26200.9168, x64
• Codex Desktop app package: OpenAI.Codex 26.803.10989.0 (x64)
• Bundled Codex runtime recorded in the session: 0.147.0-alpha.6.6
• Standalone Codex CLI on PATH: codex-cli 0.145.0
• PowerShell: 7.6.4
• Git for Windows: 2.55.0.windows.2
• Locale: ja-JP
• Time zone: Tokyo Standard Time
• Workspace: a local Git repository on the system drive

The relevant session metadata was:

originator = Codex Desktop
source = vscode
cli_version = 0.147.0-alpha.6.6
approval_policy = never
sandbox_policy = danger-full-access
permission_profile = disabled
filesystem = unrestricted

I am using the standalone Codex Desktop app, not the VS Code extension. The source = vscode value above came from the Desktop-created session metadata.

Permission state after restart

One potentially relevant detail is how Full Access was enabled:

1. I had selected Full Access previously.
2. Codex Desktop was later restarted; the PC had also been restarted.
3. When Codex started again, Full Access was already selected automatically because the previous setting had been restored.
4. I did not manually reselect or toggle Full Access immediately before reproducing the problem.

Therefore, this was not a permission upgrade made during the active turn. The task started with the app already displaying the previously persisted Full Access state.

Observed behavior

While continuing ordinary repository work, Codex attempted to stage changes with git add. The command was rejected with:

approval required by policy, but AskForApproval is set to Never

Other shell and repository inspection commands in the same task succeeded, so this was not a general failure to start PowerShell or Git.

Expected behavior

When the effective runtime context is approval_policy = never, sandbox_policy = danger-full-access, and permission_profile = disabled, git add should run without requesting approval.

Possible relevance

This may indicate that, after an app or PC restart, the persisted Full Access selection and the permission context visible to the agent are restored, while a separate command-approval or execution-policy component retains or reconstructs an incompatible state.

It may be useful to check whether permission state restored during application startup is applied atomically to all execution-policy components, rather than only to the UI and thread context.