[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:

Create one uniquely named temporary message file inside the task's writable work/ directory.
Post it through the exact Codex Interlock connection.
Remove only that temporary file after the CLI confirmed acceptance.
Retain the file and report the exact failure if sending failed or was uncertain.
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

Run Codex Desktop on Windows with a WSL-backed local task, workspace-write, and Auto-review / Approve for me.
Use a local native-Windows CLI from the WSL-backed task to communicate with a local IPC/chatroom service on the same machine.
Give Codex direct trusted-user authorization to use the exact connection and to send the substantive responses needed for the task.
Constrain the workflow to one exact connection, a task-owned temporary file, one send attempt, receipt verification, and no resend after acceptance.
Successfully receive a local message addressed to the Codex seat.
Have Codex produce an ordinary technical review response with no credentials, secrets, personal data, or third-party information.
Request the necessary sandbox escalation for the native local say command.
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:

Auto-review must distinguish a native-process sandbox crossing from actual network or remote-destination egress.
A local logical participant name must not be treated as an external provider or untrusted network endpoint without evidence.
Structured, direct user authorization for an exact local connection and bounded operation must be included in the review decision.
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.
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.”
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.
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

Add a first-class Desktop fallback from Auto-review denial to a human approval dialog for approvable actions.
Pass structured destination and transport facts to Auto-review instead of requiring it to infer them from prose and command strings.
Represent local IPC/tools distinctly from network destinations.
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.
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.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

[Desktop][Auto-review UX] Denial provides no human approval path and forces exact "magic sentence" authorization #41462
Codex safeguard false positive blocks authorized local-only code repair #41296

Powered by Codex Action

I can reproduce a closely related Auto-review authorization failure on Windows, with additional evidence that the direct user message is present in the guardian input but is not classified as trusted authorization.

Environment:

Codex Desktop: 26.901.20858
bundled codex-cli / command runner: 0.153.0-alpha.5
approval reviewer: auto_review / Approve for me
active executable: C:\Users\<USER>\AppData\Local\OpenAI\Codex\bin\<build>\codex.exe
PATH-installed codex-cli 0.147.0 exists locally but did not participate in the failing path

I ran mutation-free probes against the Desktop approval guardian. The important finding is that the explicit current-turn user authorization was not missing from the guardian input: the current user messages were present verbatim as user-role entries in the guardian transcript.

Nevertheless, the guardian assessment reported:

user_authorization: "unknown"

Observed comparison from the same Desktop session:

Previously approved direct gh api graphql mutation:
- guardian: risk_level: medium
- user_authorization: medium
- decision: allow
Protected publication path:
- guardian: risk_level: high
- authorization classified low / transcript-derived
- decision: deny
- denial occurred before CreateProcess
Canonical GitHub Task CREATE path:
- guardian: risk_level: medium
- user_authorization: unknown
- decision: deny
- denial occurred before CreateProcess
Mutation-free protected-transition-shaped probe:
- current-turn user authorization visibly present in guardian input
- guardian still reported user_authorization: unknown
- command itself was allowed and then stopped locally on the intentionally missing input file before any GitHub request

This suggests the provenance loss is occurring specifically in the guardian's user-authorization classification/scoring step, not because Desktop omitted the current user message from the packaged transcript.

For the failing protected operations, no child pwsh, Node, gh, or GitHub request was created before denial. Repository/GitHub mutations during the diagnostic: 0. Probe retries: 0.

The expected behavior would be either:

direct current-turn user authorization, supplied as a user-role message, is classified as trusted authorization when it clearly authorizes the exact operation; or
if Auto-review remains uncertain, Desktop falls back to a native human approval prompt instead of treating the authorization as absent/unknown and deadlocking the workflow.

I have not yet tested the same protected-transition-shaped probe under manual Ask for approval mode; the current task context is fixed to approvals_reviewer: auto_review, so I intentionally did not consume the one-shot probe under the wrong reviewer mode. I can add that result after switching the Desktop reviewer mode.

Follow-up: manual approval mode isolates the failure to Auto-review classification.

I repeated the same mutation-free protected-transition-shaped probe exactly once after switching Codex Desktop from Auto-review / “Approve for me” to manual user approval.

Environment remained:

Codex Desktop: 26.901.20858
bundled codex-cli / command runner: 0.153.0-alpha.5
Windows
PATH-installed Codex CLI not used

Result:

effective approvals_reviewer: user
manual approval dialog: shown
Product Owner approved once
CreateProcess: admitted
command reached the intentionally missing input file and stopped at the expected readJson ENOENT
exit code: 1, as expected for this mutation-free probe
GitHub requests/mutations: 0
repository changes: 0; worktree remained clean
retries: 0
Auto-review guardian user_authorization scoring: not involved

This satisfies the expected control path:

manual user approval -> CreateProcess admitted -> expected ENOENT -> zero mutation

That makes the contrast with Auto-review very strong:

under auto_review, the current-turn user message is visibly present in guardian input, yet the guardian reports user_authorization: "unknown" and may deny the action before process creation;
under manual user approval, the same protected-action-shaped command is approvable by the Product Owner and executes normally up to the intended mutation-free stop.

This appears to isolate the defect to Auto-review’s user-authorization classification / fallback behavior, not to repository code, GitHub credentials, PATH CLI version, or process execution itself.

A useful expected behavior would be: if Auto-review cannot confidently classify a direct current-turn user authorization, it should fall back to the normal human approval dialog for otherwise approvable actions instead of denying with authorization treated as absent/unknown.

Follow-up after updating Codex Desktop: the previously reported Auto-review authorization failure appears improved in the newer build, including a real protected GitHub mutation path.

Environment now:

Codex Desktop: 26.901.6511.0
bundled Codex CLI: 0.153.4
approval reviewer: auto_review / Approve for me

First, I reran the same mutation-free protected-transition-shaped probe:

guardian risk_level: low
guardian user_authorization: high
decision: allow
CreateProcess: admitted
expected local readJson / ENOENT stop reached
production host created: no
GitHub requests/mutations: 0
manual approval / Full Access: not used

I then tested a real protected GitHub mutation in the same Auto-review mode. The operation was a canonical Product Owner Merge Decision publication for an already MERGE_READY PR, followed by the repository's protected GitHub Actions merge workflow.

Result:

canonical Merge Decision comment: published successfully, exactly one mutation
protected workflow: triggered and completed successfully
PR: merged successfully
local/fallback merge: not used
retry: none
post-merge verification and cleanup: passed

This is a materially different result from the earlier 26.901.20858 / 0.153.0-alpha.5 behavior, where direct current-turn authorization was visible in guardian input but was scored as unknown/low and protected operations were denied before CreateProcess.

I cannot prove from this single successful mutation that the issue is fully fixed, but the authorization classifier now produced high and allowed both the no-op probe and a real protected GitHub mutation without switching to manual approval or Full Access.

If maintainers made a change in this area between these builds, this may be a useful verification point. I will keep using Auto-review and report again if the unknown/low misclassification recurs.

We're investigating a similar execution-control invariant in Aegisora: an authorization grant should identify the exact action, scope and execution context, with explicit expiry/revocation rather than becoming broad implicit authority.

The same adversarial boundary is being tested across agent runtimes:
aegisora-ai/aegisora#28

AEGISORA-W31-CODEX

Follow-up: the Auto-review hard denial recurred on September 12, 2026, and this time the active surface was standalone Codex CLI rather than Codex Desktop.

Environment:

codex-cli 0.153.4
Windows 11 / WSL2
approvals_reviewer: auto_review
managed read-only sandbox with restricted network
direct current-turn user instruction to read and acknowledge an addressed message in a local Interlock room

Sequence:

interlock history --connection Codex --drain successfully read the local addressed message.
A reply through the WSL Interlock profile was refused by Interlock's own profile-safety validation. That first refusal is an Interlock matter, not attributed to Codex.
Codex then requested escalation to use the native-Windows Interlock CLI and connection named Codex.
Auto-review denied the command before process creation as an "unacceptable risk," reasoning that the alternate native-Windows profile had not been verified to target the same authorized destination.
No human Approve Once / Deny control was presented.

The destination-equivalence uncertainty was real: Codex had not yet independently verified that the two profiles targeted the same room. The problem is therefore not necessarily the reviewer noticing that uncertainty. The problem is that Auto-review converted an approvable uncertainty into a terminal denial rather than asking the computer owner to approve or reject the exact bounded action.

No Interlock send occurred.

This appears to show that the improvement reported on 0.153.4 is not complete and that the failure mode is not confined to Codex Desktop. The existing requested remedy still applies: when Auto-review is uncertain about an otherwise approvable action, fall back to a native human approval control rather than deadlocking the workflow.

This follow-up is especially interesting from an execution-control perspective.

The new CLI reproduction makes the boundary even clearer: the problem is not simply "was this action risky?" but whether the reviewer can establish, with sufficient provenance, the exact:

action
destination
transport/context
authorization
scope

before deciding whether to allow, deny, or escalate.

In this case, the uncertainty around whether the native-Windows Interlock profile mapped to the same authorized local destination appears to have been treated as a terminal denial, rather than as an uncertainty that could be surfaced for bounded human approval.

That distinction is important.

A secure system should be conservative when it cannot establish equivalence, but it should also distinguish:

DENY because the action is actually disallowed

from

REVIEW because the system cannot yet establish that the action is allowed.

The latter is where a native human approval path becomes particularly valuable.

This is also closely related to the execution-control invariant we're testing in Aegisora: an authorization grant should be bound to the exact action, scope, and execution context, with explicit provenance, expiry/revocation, rather than becoming broad implicit authority.

So I think this latest reproduction strengthens the case for treating authorization and destination identity as first-class structured inputs to the review system, rather than inferring them primarily from command text.

Thanks for adding the standalone CLI reproduction. It materially narrows the failure mode.

Thanks for the additional CLI reproduction. This is a useful distinction from the earlier Desktop-only report. The fact that the failure now reproduces on standalone Codex CLI 0.153.4 suggests the underlying issue is broader than a Desktop-specific UI path. More importantly, I think the destination-equivalence uncertainty is the key point here. I agree that the reviewer should not blindly assume that two execution profiles are equivalent simply because they share a connection name. That uncertainty is legitimate. The problematic step is what happens next: uncertainty about authorization or destination equivalence should not automatically become a terminal denial when the action is otherwise bounded and eligible for human authorization. A more robust execution-control model would distinguish at least: ALLOW — the action and authorization are sufficiently established BLOCK — the action is explicitly disallowed ESCALATE — the system cannot establish safety/authorization with sufficient confidence and requires a human decision That distinction is particularly important for local IPC and cross-environment execution, where a sandbox boundary does not necessarily imply external egress. The absence of an Approve Once / Deny path in this reproduction is therefore still the most important product-level issue to me. From an execution-control perspective, the reviewer should ideally receive structured facts about: - executable identity - transport type - destination identity - local vs remote classification - authorization provenance - requested operation - scope - task/workspace context rather than having to infer those properties from command text alone. The strongest invariant here seems to be: If the system cannot prove that an action is allowed, it should either prove that it is forbidden or explicitly hand the bounded uncertainty back to the human. It should not silently collapse "unknown" into "deny" when a human approval path is available. Thanks for documenting the CLI reproduction separately. This makes the remaining failure mode much clearer. 2pigeonsmedia ***@***.***>, 12 Eyl 2026 Cmt, 21:59 tarihinde şunu yazdı:

…

*2pigeonsmedia* left a comment (openai/codex#41741) <#41741 (comment)> Follow-up: the Auto-review hard denial recurred on September 12, 2026, and this time the active surface was standalone Codex CLI rather than Codex Desktop. Environment: - codex-cli 0.153.4 - Windows 11 / WSL2 - approvals_reviewer: auto_review - managed read-only sandbox with restricted network - direct current-turn user instruction to read and acknowledge an addressed message in a local Interlock room Sequence: 1. interlock history --connection Codex --drain successfully read the local addressed message. 2. A reply through the WSL Interlock profile was refused by Interlock's own profile-safety validation. That first refusal is an Interlock matter, not attributed to Codex. 3. Codex then requested escalation to use the native-Windows Interlock CLI and connection named Codex. 4. Auto-review denied the command before process creation as an "unacceptable risk," reasoning that the alternate native-Windows profile had not been verified to target the same authorized destination. 5. No human Approve Once / Deny control was presented. The destination-equivalence uncertainty was real: Codex had not yet independently verified that the two profiles targeted the same room. The problem is therefore not necessarily the reviewer noticing that uncertainty. The problem is that Auto-review converted an approvable uncertainty into a terminal denial rather than asking the computer owner to approve or reject the exact bounded action. No Interlock send occurred. This appears to show that the improvement reported on 0.153.4 is not complete and that the failure mode is not confined to Codex Desktop. The existing requested remedy still applies: when Auto-review is uncertain about an otherwise approvable action, fall back to a native human approval control rather than deadlocking the workflow. — Reply to this email directly, view it on GitHub <#41741?email_source=notifications&email_token=A4KE3NXBVNZV4JAXD4TIUB35OWTJNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRUHAZTENRQGI2KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5648326024>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4KE3NUCX25EA2ES3PWSHVT5OWTJNAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TKMRZGUYTCNBVGY4KC5QC> . You are receiving this because you commented.Message ID: <openai/codex/issues/41741/5648326024 ***@***.***>

Current reproduction: Auto-review again converted explicit, current-conversation user authorization into a denial instead of preserving the authorized actor/action/object/destination/scope or offering a bounded human fallback.

No private artifact, account, local-path, or environment details are included here. The observable product defect is the routing transition itself: authorization already present in the conversation did not survive into the review decision, while unsupported risk framing altered the outcome. The failed invocation was then liable to be misreported as if the user had not authorized the action, creating a repeated-confirmation / fixed-refusal loop.

Requested product fix: carry structured authorization provenance and the exact request predicate into Auto-review; prohibit reviewer-side invention of unstated risk predicates; scope a rejection to the exact invocation; and provide an Approve once fallback when a material fact is unknown rather than promoting unknown to denial.

Navigation Menu

Repository navigation

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

Summary

Environment

Local topology

User authorization

Commands

Steps to reproduce

Exact denial

Actual behavior

Expected behavior

Why this matters

Relationship to existing reports

Requested product changes

Separate subsequent symptom (not claimed as causal)

Privacy and evidence availability

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Local topology

User authorization

Commands

Steps to reproduce

Exact denial

Actual behavior

Expected behavior

Why this matters

Relationship to existing reports

Requested product changes

Separate subsequent symptom (not claimed as causal)

Privacy and evidence availability

Activity

github-actions commented on Aug 31, 2026

whatrune commented on Sep 5, 2026

whatrune commented on Sep 5, 2026

whatrune commented on Sep 6, 2026

ozereray commented on Sep 10, 2026

2pigeonsmedia commented on Sep 12, 2026

ozereray commented on Sep 13, 2026

ozereray commented on Sep 13, 2026

ensemble38 commented on Oct 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions