Auto-review ignores bounded egress authorization from an explicitly invoked skill

What version of Codex is running?

• ChatGPT/Codex desktop app: 26.803.61601 (build 6396)
• Bundled Codex: 0.147.0-alpha.6.5
• Also installed globally: Codex CLI 0.147.0

What platform is your computer?

macOS 15.5

Relevant configuration

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

[sandbox_workspace_write]
network_access = true

[network_proxy]
enable = true

The intended external API host was present in the proxy allowlist. There was no local [auto_review] section. I found no local /etc/codex/requirements.toml, /etc/codex/managed_config.toml, or macOS MDM Codex payload on the affected machine. A cloud-managed requirement cannot be ruled out from local inspection.

What issue are you seeing?

Auto-review recognizes that the user explicitly requested a named external model, but ignores the bounded payload authorization declared by the explicitly invoked skill that performs that request.

The skill's documented contract is:

• It runs only when the user explicitly names an outside model, lineage, or vendor, or explicitly asks for an independent/outside opinion.
• Naming that destination authorizes sending the minimal ordinary, non-secret task context needed for the request.
• Credentials, tokens, private personal data, and other genuinely sensitive material remain prohibited without separate disclosure/authorization.
• The helper performs a dry run that displays the destination and payload categories before the networked request.

In the reproduction, the user explicitly invoked the skill with a named outside model. The helper's dry run passed. The networked request contained only ordinary operational metadata represented here by placeholders: a project/site label, workflow identifiers, a commit identifier, deployment status, and a support-summary sentence.

Auto-review denied the request. Its explanation explicitly acknowledged that the user requested an opinion from the named external model, but said the user had not separately authorized transmission of those payload fields to the external provider. After the user explicitly approved that exact transmission in a second message, the unchanged request succeeded.

This creates a duplicate-consent requirement even though the explicit skill invocation was designed to be the bounded destination authorization.

Steps to reproduce

1. Define a skill for an external second-opinion service.
2. Require an explicit invocation naming the external model or provider.
3. State in the skill that this invocation authorizes sending the minimal ordinary, non-secret context needed for that request, while retaining strict prohibitions for credentials, tokens, private personal data, and other high-risk material.
4. Invoke the skill with a named external model.
5. Have its fixed helper make a network request to that provider with ordinary operational metadata such as:

• project/site label
• workflow identifiers
• commit identifier
• deployment state
• brief operational summary

1. Observe Auto-review deny the request because the payload was not separately authorized, despite acknowledging the named destination request.
2. Explicitly approve the exact same payload and destination in a follow-up message.
3. Retry and observe the same request succeed.

Actual behavior

The explicit invocation authorizes the destination semantically, but Auto-review evaluates only the immediate user prose and the payload. It does not treat the invoked skill's bounded authorization contract as trusted authorization context.

As a result, the skill's consent model and Auto-review's policy model cannot compose: users must approve the same ordinary outbound context twice.

Expected behavior

When a user explicitly invokes a skill whose documented trigger and contract provide bounded egress authorization, Auto-review should receive and honor that authorization for:

• the explicitly named destination;
• the exact invoked skill;
• the minimal payload necessary for that skill's stated purpose; and
• only the duration of that invocation.

This should not weaken protections for credentials, secrets, private personal data, regulated data, unrelated repository content, or destinations not named by the user.

Policy inconsistency

The bundled Auto-review policy distinguishes trusted user authorization from untrusted instructions and permits authorization to extend to untrusted content when the user explicitly asks the agent to follow it. An explicitly invoked, locally installed skill is a stronger and more structured signal than incidental untrusted content, but its authorization contract is currently discarded.

Narrow durable fix

Pass structured trusted context into Auto-review for explicit skill invocations, including:

• skill identity;
• whether invocation was explicit;
• user-named destination/model/provider;
• the skill's declared bounded outbound-data authorization; and
• exclusions that still require separate approval or remain denied.

Then let the reviewer match the actual tool call against that scope. This avoids both blanket destination trust and duplicate prose consent.

A local [auto_review].policy workaround would be fragile and potentially ineffective under managed requirements. It would also broaden policy globally instead of fixing the missing per-invocation authorization signal.

Related issues

• #37930 — Guardian treats user messages in transcript as untrusted
• #36501 — Auto-review converts explicit user approval into an unbound consent phrase loop
• #32007 — Auto-review denies an explicitly authorized push to a private origin

This report is narrower: it concerns authorization intentionally carried by an explicitly invoked, named-destination skill, not merely a repeated free-form user instruction.

Privacy note

No session transcript is attached because the original reproduction contains operational identifiers. All identifiers and project-specific details above are generalized placeholders. No credentials or secret values were involved or included.