Windows Desktop: no visible human-approval prompt for require_escalated read; execution reports CodexSandboxOffline

What version of the Codex App are you using (From “About Codex” dialog)?

Previously user-reported Windows desktop version: 26.901.6511.0. This is historical, not a fresh About-dialog verification. A recent process FileVersion/ProductVersion query returned empty fields, so the current desktop version remains unverified.

The separately installed executable reports codex-cli 0.151.0 (codex.exe --version, exit 0). That does not establish the desktop runtime version.

What subscription do you have?

Personal ChatGPT account (user-reported); subscription tier not established in this diagnostic.

What platform is your computer?

Windows, using PowerShell. Exact Windows build is not included.

What issue are you seeing?

Selecting Ask for approval is reflected in retained task context, but the user reported no visible approval card for an explicitly escalated, read-only Git request. The command started, yet Git identified its executing account as CodexSandboxOffline and rejected repository ownership.

There are three observations; a shared cause has not been established:

1. Before the mode change, a bounded read-only Git request and one identical retry returned automatic permission-review deadline timeouts. No command output or running command-session identifier was returned.
2. After selecting Ask for approval, retained context changed from approvals_reviewer=auto_review to approvals_reviewer=user. It recorded:

   approval_policy=on-request
   approvals_reviewer=user
   sandbox_policy.type=workspace-write
   network_access=false
   

   An exec_command request with sandbox_permissions="require_escalated" and an explicit approval question then ran, but returned Git's fatal: detected dubious ownership in repository error (exit 1). Git reported the repository owner as the desktop user and the executing identity as CodexSandboxOffline. The user explicitly reported that no approval card appeared. The agent did not independently observe the UI or a human approval event.
3. Two in-app feedback attempts displayed Feedback upload not confirmed. The dialog warned that the report might already have arrived, so both receipts remain unknown. We have no evidence that changing diagnostic/browser-log checkboxes would fix delivery.

What steps can reproduce the bug?

This is the observed workflow in an existing affected task, not a clean-profile reproduction. No new execution attempt was made for this issue.

1. In the Windows desktop app, select Ask for approval.
2. Confirm that the next retained task context records on-request and reviewer user.
3. Request the following read-only command through exec_command, orchestrated by functions.exec, with sandbox_permissions="require_escalated" and a human-readable approval question:

   & '<GIT_EXE>' --no-optional-locks -C '<EXISTING_TASK_WORKTREE>' rev-parse --show-toplevel --git-common-dir HEAD
   

   These placeholders redact identifying local paths. The command does not write files, change Git state, use the network, install packages, or delete anything.
4. Observe the ownership rejection described above and the user's report that no prompt appeared.

What is the expected behavior?

Please identify the actual approval and execution decision:

• Was an approval request created and delivered to the desktop UI?
• If no prompt was required, which policy/rule/previous approval authorized execution?
• Did the tool/orchestration bridge preserve require_escalated through to the Windows executor, and why was the sandbox account used?
• What is the supported path for an allowed, approved, non-mutating read of an owner-held worktree without changing repository trust or ownership?
• Are the auto-review timeouts and unconfirmed feedback receipts separate issues?

This is not a request for unrestricted access or to override a policy denial.

Additional information

Rule-check limits: The supported codex execpolicy check against user-layer default.rules, for the exact direct Git argv, returned exit 0 and {"matchedRules":[]}. A separate inspection of 27 user-layer prefix rules found no literal match for that direct argv. The actual shell-wrapper argv and other effective policy layers were not conclusively established; we are not claiming that all possible cached/rule approvals were excluded.

Saved versus active configuration: Saved user defaults still recorded approval_policy="never", approvals_reviewer="auto_review", and a custom named permissions profile. Active task values were the human-review values above. The task also describes its permission profile as managed; this does not establish an organization account or identify the source of the policy. These differences are observations, not asserted causes.

Related reports inspected: #41161 concerns approved commands remaining sandboxed in the CLI, with Desktop reportedly working; this observation is in Desktop with human review and no observed prompt. #37187 describes interruption-related desktop sandbox identity problems, but its trigger and full-access configuration were not reproduced here. #43436 contains the same unconfirmed-feedback message while reporting a different browser restriction. These links do not establish a common cause.

Safety and privacy: A separate dependency cleanup was explicitly denied and was not retried through another channel. No ACL, ownership, safe.directory, or security-policy weakening was used. No private repository source or name, actual local paths, credentials, Windows SID, machine name, session/task ID, full configuration, browser logs, or raw diagnostic logs are attached. Private correlation details are retained locally and can be considered through an appropriate support channel after review.

Start by tracing the functions.exec and exec_command path for sandbox_permissions="require_escalated", then compare it with the supported codex execpolicy check and user-layer default.rules behavior. Establish whether an approval request reaches the Windows desktop UI and whether the executor preserves the requested permission and identity. Done means explaining the sandbox identity and separating the approval, timeout, and feedback-receipt observations.