User-approved external CLI calls are still blocked as local file exfiltration, with no actionable override

Problem

Codex blocks a user-approved local CLI call because it detects that local workspace files would be sent to an external API.

The frustrating part is not that Codex is cautious by default. The issue is that even after the user explicitly approves the action, the execution layer still rejects it, and there is no actionable way to continue from inside Codex.

Repro shape

A local CLI wraps third-party model providers:

node bin\huannaozi.js second-opinion `
  --profile packy_sonnet `
  --task "Review facts in this local draft" `
  --file "E:\...\draft.txt" `
  --output "E:\...\review.json"

The selected profile sends the file content to an external OpenAI-compatible endpoint:

https://www.packyapi.com/v1

Codex asks for/receives user approval, but the command is still rejected as external exfiltration of private workspace files.

Actual behavior

The command is rejected even after explicit user approval.

This makes local model-router CLIs unusable from Codex for tasks like:

• sending a draft to another model for review
• using a user-configured relay provider
• running a local second-opinion CLI over files the agent itself just generated
• verifying factual accuracy of content that Codex itself researched and wrote

In the real case that triggered this issue, Codex searched public web sources, generated a local draft and a local review note from those sources, and then could not send that same Codex-generated draft to another model for a factuality review. The practical result is that material gathered and written by Codex can only be processed by Codex, even when the user explicitly wants an independent model to check it.

That is a bad trust model. Users should be able to decide that their own local draft, especially one generated from public web research inside Codex, can be sent to a configured review provider. Otherwise Codex effectively forces users to accept Codex as the only reviewer of Codex-generated content. A useful analogy: it feels like depositing money in a bank and then being told the bank will not let you withdraw or transfer it. The current behavior feels less like safety and more like an overbroad lock-in caused by a blunt policy.

It also creates a bad UX: the assistant asks the user for permission, the user approves, and only then Codex says the action is impossible.

Expected behavior

One of these would be much better:

1. Allow explicit user approval to override this class of external API calls.
2. Provide a clear preflight result saying "this cannot be approved in this environment" before asking the user.
3. Allow a per-domain or per-command trust rule for local CLIs that intentionally call external model APIs.
4. Allow sending user-selected files when the user explicitly names both the files and the destination provider.
5. Expose a clearer error explaining the policy boundary and what users can configure.

Why this matters

Many users have local CLIs that intentionally call external providers. Treating every local file -> external API flow as unconditionally forbidden makes Codex unable to orchestrate common local workflows, even when the user owns the files, explicitly requested the action, and approved the destination.

The current behavior is over-conservative and, frankly, very weak UX. It makes Codex look broken rather than safe.