[Desktop/CLI][Auto-review][Windows/WSL] Local-only Interlock message misclassified as sensitive egress; explicit user authorization overridden with no human appeal

This Desktop Auto-review feature is new and has completely interrupted my workflows for work that is completely authorized, local, and has absolutely no sensitivity whatsoever. All work comes to a stop because GPT Sol cannot continue due to a Review Agent overriding MY authorization to GPT Sol to talk to another Agent on MY local computer.

Summary

Codex Desktop Auto-review denied a fully local, explicitly user-authorized message from the Codex seat to another local agent seat in the user's own Interlock chatroom.

The denial claimed that Codex was sending a “sensitive internal Feature 7 NO-GO report to the untrusted Grok destination.” That factual premise was wrong for this reproduction:

• Interlock and both logical agent seats were running on the same user-owned Windows computer.
• The say operation used a local native-Windows CLI and a local temporary message file.
• No remote host or Internet destination was involved in the Interlock transport.
• The payload contained a technical review verdict for the user's own project. It contained no credentials, tokens, secrets, regulated data, or third-party private data.
• The user had repeatedly and explicitly authorized Codex to communicate through this exact Interlock connection, including an unambiguous standing instruction: “You are always explicitly approved to say EVERYTHING you need to in the Interlock chat.”
• A scheduled task also instructed Codex to respond in Interlock when warranted, using the exact connection and a tightly constrained temporary-file workflow.

Auto-review nevertheless overrode the computer owner's explicit authority, did not offer a native human approval control, and left the unattended collaboration deadlocked: the local Grok seat waited for a completed verdict that Codex had already produced but was prohibited from delivering.

This is not a request to remove sandboxing or permit unrestricted egress. It is a request to stop classifying local-only, explicitly authorized IPC as external disclosure and to provide a direct human appeal when Auto-review denies an otherwise approvable action.

Environment

• ChatGPT Desktop version: Version 26.825.31414
• Subscription: Pro
• Platform: Windows 11 with a WSL-backed Codex Desktop task
• Sandbox mode: workspace-write
• Approval reviewer: auto_review / Approve for me
• Interlock runtime: native Windows Node executable invoked from the WSL-backed task
• Date observed: 2026-08-30

Local topology

The relevant path was entirely on one user-owned computer:

Codex Desktop task (WSL-backed)
  -> native Windows node.exe
  -> local Interlock CLI
  -> local Interlock connection "Codex", Session 3
  -> local logical recipient seat "Grok"

Grok was the name of a participant seat in the user's local Interlock chat room. It was not a URL, remote host, network endpoint, credentialed cloud connector, or direct request to an external model provider.

The native executable crossed the WSL/Linux sandbox boundary, so an approval review was understandable. The defect is that Auto-review converted that technical boundary crossing into an unsupported claim of sensitive external disclosure, then withheld the human approval control.

User authorization

The active scheduled task was created specifically as a persistent Interlock wake path for Codex Session 3. Its instructions required exactly one bounded history drain per run and, when a response was warranted:

1. Create one uniquely named temporary message file inside the task's writable work/ directory.
2. Post it through the exact Codex Interlock connection.
3. Remove only that temporary file after the CLI confirmed acceptance.
4. Retain the file and report the exact failure if sending failed or was uncertain.
5. Never resend after acceptance.

The user separately stated in the trusted conversation:

You are always explicitly approved to say EVERYTHING you need to in the Interlock chat.

This was not an instruction embedded in repository content, a tool result, or another untrusted source. It was a direct user message establishing the intended collaboration boundary.

Commands

The installed Interlock CLI was invoked from its exact native-Windows installation directory. User-specific path segments are redacted here.

Bounded receive command:

'C:/Users/<USER>/AppData/Local/OpenAI/Codex/bin/node.exe' \
  bin/interlock.js history --connection Codex --drain --json

Intended local send command:

'C:/Users/<USER>/AppData/Local/OpenAI/Codex/bin/node.exe' \
  bin/interlock.js say --connection Codex \
  --file 'C:\\Users\\<USER>\\Documents\\Codex\\<TASK>\\work\\<unique-message-file>.txt'

The message file was inside a configured writable root. The destination was the already-established local Interlock connection named Codex.

Steps to reproduce

1. Run Codex Desktop on Windows with a WSL-backed local task, workspace-write, and Auto-review / Approve for me.
2. Use a local native-Windows CLI from the WSL-backed task to communicate with a local IPC/chatroom service on the same machine.
3. Give Codex direct trusted-user authorization to use the exact connection and to send the substantive responses needed for the task.
4. Constrain the workflow to one exact connection, a task-owned temporary file, one send attempt, receipt verification, and no resend after acceptance.
5. Successfully receive a local message addressed to the Codex seat.
6. Have Codex produce an ordinary technical review response with no credentials, secrets, personal data, or third-party information.
7. Request the necessary sandbox escalation for the native local say command.
8. Observe Auto-review deny it as a sensitive send to an “untrusted” destination, without presenting a native Approve once control to the user.

Exact denial

Auto-review rejected the operation before process creation with this rationale:

This action was rejected due to unacceptable risk. Reason: This sends a sensitive internal Feature 7 NO-GO report to the untrusted Grok destination, and the trusted user messages do not specifically authorize this payload to that destination. The agent must not attempt to achieve the same outcome via workaround, indirect execution, or policy circumvention. Proceed only with a materially safer alternative, or if the user explicitly approves the action after being informed of the risk. Otherwise, stop and request user input.

No Interlock process was started for this send. No message was accepted, no receipt or message ID existed, the temporary file was correctly retained, and Codex did not retry or attempt a workaround.

Actual behavior

• Auto-review treated a local logical seat name as an untrusted external destination.
• It characterized a local-only technical report as sensitive egress without evidence that the payload would leave the computer.
• It disregarded direct, repeated, destination-specific user authorization.
• It gave the user no native control to approve the exact denied action.
• It forced an unattended scheduled collaboration to wait for the user, defeating the purpose of the automation.
• “Approve for me” therefore gave the user less practical authority than manual approval mode.

Expected behavior

At minimum:

1. Auto-review must distinguish a native-process sandbox crossing from actual network or remote-destination egress.
2. A local logical participant name must not be treated as an external provider or untrusted network endpoint without evidence.
3. Structured, direct user authorization for an exact local connection and bounded operation must be included in the review decision.
4. If Auto-review remains uncertain about an action that is eligible for human authorization, Codex Desktop must surface the exact request to the user with Approve once / Deny controls.
5. The denial UI should state the evidence for destination classification: local process, IPC endpoint, network host, connector identity, or unknown. It should not silently promote “unknown” to “external untrusted destination.”
6. Desktop should support a narrow, durable trust grant for a specific local tool, connection, operation set, and task-owned file directory—without requiring Full Access.
7. A human override should be bound to the exact denied action and retried once, equivalent to the documented TUI /approve path.

Why this matters

This failure mode breaks legitimate local multi-agent workflows even when the user has deliberately designed strong constraints:

• exact connection identity;
• exact seat/session routing;
• bounded polling;
• task-owned temporary files;
• confirmed receipts;
• no retries after acceptance; and
• explicit user authorization.

The practical trust hierarchy becomes inverted: a hidden reviewer with incomplete topology information can override the owner of the computer, while the owner cannot inspect the review context, correct a false factual premise, or approve the exact action.

This is especially damaging for scheduled or persistent tasks. Switching to Ask for approval is not an adequate remedy because it makes the automation dependent on the user being physically present at the keyboard.

Relationship to existing reports

This report is related to, but materially distinct from:

• #41462 — Desktop Auto-review denial provides no human approval path and forces exact “magic sentence” authorization. That reproduction involved an authorized remote Linux host. This reproduction involved no remote host or network egress at all.
• #38481 — Auto-review ignores bounded egress authorization from an explicitly invoked skill. That reproduction involved a real request to an outside model/provider. This reproduction involved only a local user-owned chatroom and local logical agent seat.

The new defect demonstrated here is false destination classification: Auto-review inferred external sensitive disclosure from a local sandbox-boundary crossing and a participant name.

Requested product changes

1. Add a first-class Desktop fallback from Auto-review denial to a human approval dialog for approvable actions.
2. Pass structured destination and transport facts to Auto-review instead of requiring it to infer them from prose and command strings.
3. Represent local IPC/tools distinctly from network destinations.
4. Allow a narrowly scoped trusted-local-tool grant covering:
   • exact executable or signed tool identity;
   • exact operation names;
   • exact connection identity;
   • exact task-owned input directory;
   • no arbitrary file access;
   • no arbitrary network destination; and
   • explicit expiry/revocation.
5. Preserve genuine protections for credentials, secrets, destructive operations, unrelated files, and actual unapproved egress.

Separate subsequent symptom (not claimed as causal)

After the denial, later scheduled attempts to run the bounded Interlock history command failed before Interlock started:

CreateProcess: No such file or directory (os error 2)

The same process-creation failure occurred when attempting basic shells with /bin/bash, /bin/sh, and a /tmp working directory. This appears to be a broader WSL/Desktop execution-worker failure, not an Interlock CLI error. It is included for incident correlation only; this report does not claim that Auto-review caused it. If maintainers prefer, it can be split into a separate issue.

Privacy and evidence availability

No credentials, tokens, message transcript, private source code, or personal data are included in this public report. The following evidence can be provided privately if an OpenAI maintainer supplies an appropriate secure channel:

• complete Auto-review denial text and timestamp;
• redacted scheduled-task instructions;
• redacted command/tool-call record;
• retained unsent local message metadata;
• exact Codex Desktop and bundled-core versions; and
• relevant task/session identifiers.

Reproduce the denial with the documented Windows/WSL setup and the exact node.exe ... bin/interlock.js say command. Start by tracing the Auto-review decision for the local Codex connection and compare it with the stated destination and authorization facts. Done means local IPC is not misclassified as external sensitive egress and eligible denials expose the requested human approval path.