Changing /permissions to Ask for approval leaves sandbox_approval=false #52458

Summary

Selecting /permissions → Ask for approval in an active session prints
Permission selection requested: Ask for approval, but subsequent sandbox
escalation requests still fail immediately with sandbox_approval: false.
No approval prompt appears. Selecting Approve for me also leaves the same
effective granular policy in the rejection.

This may be a live permission-update issue or an enforced execution-host policy;
the latter has not been ruled out. It would help if the permission picker showed
when a requested profile cannot become the effective execution policy.

Environment

• Codex CLI: 0.162.0 (confirmed by the user with codex --version).
• Agent execution host: Linux 6.1.0-53-amd64.
• Shell: zsh.
• Initial session sandbox: workspace-write.
• No approval/sandbox override found in the accessible user config.toml.
• No /etc/codex/requirements.toml found on the agent execution host.
• Other managed policy sources and client/server configuration have not been inspected.

Steps to reproduce

1. In an existing session where shell escalation is rejected by a granular policy,
   run /permissions.
2. Select Ask for approval.
3. Observe Permission selection requested: Ask for approval.
4. Ask the agent to fetch Rust dependencies using cargo fetch with
   sandbox_permissions: "require_escalated" and a user-facing justification.
5. Observe the immediate rejection below, without an approval prompt.
6. Select Approve for me and retry: the same effective granular policy is reported.

Expected behavior

If the selected profile is allowed, it should apply to subsequent tool calls in
the active session. Ask for approval should surface a request for an eligible
sandbox escalation. If a managed or host policy blocks that profile, the client
should clearly say it was not applied and identify the effective restriction.

Actual behavior

The tool reports the original granular policy and refuses to request approval:

approval policy is Granular(GranularApprovalConfig { sandbox_approval: false, rules: false, skill_approval: false, request_permissions: true, mcp_elicitations: true }); reject command — you cannot ask for escalated permissions if the approval policy is Granular(GranularApprovalConfig { sandbox_approval: false, rules: false, skill_approval: false, request_permissions: true, mcp_elicitations: true })

The rejected tool call was:

{
  "cmd": "cargo fetch",
  "sandbox_permissions": "require_escalated",
  "justification": "May I download GPUI Kit and the remaining Rust dependencies to build the prototype?",
  "prefix_rule": ["cargo", "fetch"]
}

Ordinary shell calls remain restricted: crates.io DNS resolution fails, and
connecting to the Docker daemon socket returns operation not permitted.

Additional context

Official documentation says /permissions changes the active permissions profile
and that approval_policy.granular.sandbox_approval = true allows sandbox
escalation prompts:

• https://learn.chatgpt.com/docs/sandboxing
• https://learn.chatgpt.com/docs/config-file/config-reference

Restarting/resuming with explicit on-request flags has been suggested but has
not yet been tested. No fresh-session reproduction or session diagnostics are
available yet.