[Windows][Desktop 26.901.20858] "Approve for me" (guardian-approvals) permission mode unavailable with API-key auth (gate 3902016271)

Environmental snapshot: Windows 11 build 26200; MSIX OpenAI.Codex 26.901.1978.0; embedded App 26.901.20858; bundled app-server/CLI 0.153.0; ~/.codex uses API-key auth (preferred_auth_method = "apikey", no auth.json/auth.toml, custom provider). The local config.toml has no features.guardian_approval entry.

Repro

1. Open any conversation's permission dropdown (composer permissions control or workspace settings).

2. Observed options: "请求批准 / Ask (default)", "完全访问权限 / Full access", "自定义 / Custom (config.toml)".

3. The "帮我批准 / Approve for me (guardian-approvals)" option is absent/hidden; where surfaced elsewhere it is disabled with "需要此工作空间中的默认沙盒权限 / Requires the default sandbox permissions in this workspace".

4. config.toml currently has:

   approval_policy = "on-request"
   sandbox_mode = "workspace-write"
   [sandbox_workspace_write]
   sandbox = "elevated"
   

Expected vs Actual

Expected: "帮我批准 / Approve for me" mode (guardian-approvals: only request approval for detected risky operations) should be selectable, especially since the runtime auto-review path is active for this user.

Actual: the guardian option is unavailable for this configuration, silently.

Root-cause observations (app.asar of 26.901.20858)

• The permission dropdown derives agent modes through a selector (zto): u = isAutoReviewRequiredForSelectedModel || isGuardianApprovalEnabledByStatsig || hasAuthoritativeGuardianApprovalDefault; l = axt(resolvedConfig) ?? true, where axt(e) = Hbt(e, 'guardian_approval') and Hbt reads the boolean config.features.guardian_approval (defaults to true when absent). The guardian-approvals mode is retained only when u && l (or when it is the only available mode). isGuardianModeAvailable and showGuardianOption both descend from these values.
• isGuardianApprovalEnabledByStatsig is dynamicConfig.guardian_approval === true, and the app registers this as gate 3902016271 with featureKey guardian_approval.
• A separate helper (XNr) requires agentMode === 'auto' && !isConfigDataPending && isGuardianModeAvailable && showGuardianOption for the guardian option to appear.
• The config-to-mode resolver (ixt) maps workspace-write + a default [sandbox_workspace_write] block into auto/granular/guardian-approvals; with an explicit approval_policy = "on-request" it resolves to auto. Note: the "defaultness" check (rxt) only inspects writable_roots, network_access, exclude_slash_tmp and exclude_tmpdir_env_var; sandbox = "elevated" is not part of that check.
• Isolation: the same session runs with approvals_reviewer = auto_review (runtime automatic approval review works), so the runtime mechanism is available; only the agent-mode guardian option is gated off at the UI layer.

Correction note

An earlier draft of this issue attributed the missing mode to a non-default [sandbox_workspace_write] block and to a missing guardian-approval permission profile. Re-checking the source shows both are incorrect: rxt ignores the sandbox field, and axt is a config.features.guardian_approval boolean check that defaults to true. The most plausible gating factor is the u branch (Statsig gate 3902016271, a model-specific auto-review requirement, or an authoritative guardian-approval default) rather than the local config.

Related, not duplicates

• #39973 (retirement of approval_policy="untrusted" without an equivalent replacement; the guardian mode appears designed as its successor). This issue tracks the new UI-layer availability of that successor.
• #29915 (permission/approval mode selection does not persist for new or existing threads).
• #41462 / #41741 (auto-review UX/behavior issues, different surface).

Notes / boundaries

• Statsig runtime values and isAutoReviewRequiredForSelectedModel cannot be observed from outside the runtime, so which disjunct of u fails is not proven; the u && l structure, the gate id, and the local-config irrelevance are verified from source.
• No config/UI change was made while investigating.

Request

Please confirm whether "帮我批准 / Approve for me (guardian-approvals)" is intentionally unavailable for API-key/custom-provider setups (gate 3902016271 not enabled, or a model without an auto-review requirement); if intended, a clear in-UI explanation for why it is missing would help. If not intended, this should restore the mode or surface the actionable requirement instead of hiding it.

Start by tracing the mentioned selectors zto, ixt, XNr, axt, and the Statsig gate 3902016271 in the desktop permission-mode code. Verify which branch prevents guardian-approvals for API-key/custom-provider sessions, then confirm whether the intended result is restoring the mode or exposing a clear requirement in the UI.