Codex Desktop drops approvals_reviewer=auto_review after context compaction/resume

Summary

Codex Desktop appears to drop approvals_reviewer = auto_review from the regenerated permissions developer message after context compaction / resumed turns. After this happens, require_escalated tool calls are surfaced as manual approval prompts even though the thread originally started with auto-review enabled.

Environment

• Codex Desktop app: 26.513.31313
• Codex CLI: 0.131.0-alpha.9
• macOS
• Config:

approval_policy = "on-request"
approvals_reviewer = "auto_review"
sandbox_mode = "workspace-write"

Observed Behavior

In affected threads:

1. The initial permissions developer message contains:

``text
approvals_reviewer is auto_review: Sandbox escalations with require_escalated will be reviewed for compliance with the policy.
``

1. A context compaction event occurs.
2. The permissions developer message is regenerated after compaction.
3. The regenerated permissions message still contains sandbox settings, writable roots, and approved command prefixes, but no longer contains approvals_reviewer.
4. Subsequent require_escalated calls are shown as manual user approval prompts instead of being routed through auto-review.

Expected Behavior

If a thread/session is configured with approvals_reviewer = auto_review, regenerated permissions/runtime context after compaction or resume should preserve it. Auto-review should continue to handle eligible require_escalated requests after compaction.

Actual Behavior

After compaction/resume, the regenerated permissions context often omits approvals_reviewer, and the thread behaves as if approval review had fallen back to manual user approval.

Local Pattern

Across local session logs, this is not isolated to a single thread:

• Full permissions messages before compaction can include approvals_reviewer = auto_review.
• Regenerated permissions messages after compaction often omit it.
• In affected threads, fresh/new contexts may work, but older/resumed/compacted contexts lose the auto-review routing.

This suggests the problem is in the context rebuild / resume path, not in the user config file.

Related Issues

This may be related to other reports where old/resumed threads lose approval/auth/orchestration state while fresh threads behave correctly:

• openai/codex#22132
• openai/codex#21931
• openai/codex#18720
• openai/codex#19910
• openai/codex#18522