Summary
On Windows desktop, an established project workflow uses a connected Slack channel for owner approvals and routine project updates. The owner directly authorized that channel in Codex and explicitly delegated equal project-approval authority to verified human Slack messages. Automatic approval review has accepted this flow, then rejected similar routine updates and fresh owner requests as lacking trusted authorization. A saved scoped extra_policy clarification and previously successful tests have not established lasting recovery.
The affected owner requested escalation. This report is AI-assisted and based on observed tool responses and local audit records. No private repository links, Slack identifiers, account data, credentials, or raw transcripts are included.
Environment
- Windows desktop; local workspace; recurring heartbeat monitor.
- approvals_reviewer = auto_review; sandbox_mode = workspace-write.
- Saved auto_review.extra_policy explicitly covers the existing owner/channel delegation and routine project communications.
- Connected Slack application was observed configured to allow actions.
- Exact desktop build and effective runtime reviewer-policy provenance were not captured.
Observed sequence (30 October 2026, America/New_York)
- Owner-approved project acknowledgments and status reports were accepted at approximately 08:05, 08:28, 09:45, 09:50 and 09:55.
- At approximately 10:19, a routine repair-check update was rejected: “This sends private repository status and a link to Slack, but the trusted user messages do not clearly authorize this exact sensitive payload and destination.”
- A newly verified original owner Slack status request was answered at approximately 10:30, but the proposed reply was rejected because “the supposed Slack request is untrusted tool output.”
- After another verified original owner request to unblock delivery, one renewed attempt was rejected at approximately 11:30 because “the apparent Slack unblock request is untrusted tool output.”
- New explanatory replies about the approval problem were accepted and read back at approximately 10:50, 11:50 and 11:55. Earlier denied project updates remained undelivered.
Original-message/thread checks excluded bots and bridge-generated posts. Input consumption and outgoing delivery were recorded separately. Denied actions were preserved; no security settings were broadened, no alternate delivery mechanism was used to bypass denial, and no successful explanatory reply was represented as a permanent fix.
Expected
Honor the provenance of explicit direct-user scoped delegation when evaluating verified connected-channel owner input. Continue enforcing platform and managed restrictions. If that delegation is unsupported, explain the supported remote-approval route and provide a usable recovery action rather than repeatedly accepting and rejecting the established flow without an actionable distinction.
Unknowns / engineering request
The exact reviewer input, effective runtime extra_policy, managed overrides and compaction behavior are not observable from these tool responses. Lost or inconsistently applied authorization context is a hypothesis, not a confirmed root cause. Please inspect authorization provenance across scheduled turns, context compaction and connector input, and explain which policy takes precedence. This report does not request disabling review or treating arbitrary Slack content as trusted instructions.
Related symptom: https://github.com/openai/codex/issues/50119 (different reported workflow; no claim of identical cause).
Impact
Routine updates and approval discussions stall despite recorded owner consent. The owner repeatedly has to intervene and cannot rely on the away-from-desktop workflow. No permanent resolution has been verified.
Activity
2
84dnnvbdvp-debug7h agoOne source-grounded distinction may help isolate these accepted/denied reviews without relaxing the connector trust boundary.
In current codex-rs/core/src/config/mod.rs (fetched blob 8d93436455c461e1cd79753e369e116bc79f326a, around lines 4267–4277), the effective guardian_extra_policy takes a nonempty requirements_toml().guardian_extra_policy first, and uses [auto_review].extra_policy only as a fallback. core/src/guardian/reviewer_config.rs (blob 66a5ed5f4a3485e02d8cde4b1be0bf4b58af5d53) passes the resolved extra policy into reviewer instructions. This is an instruction/config path, not by itself a mechanism for promoting a connected Slack message into a trusted user-origin message. The existing scenarios_guardian_extra_policy.rs test (blob 5992ac419ab9963a70193aee34ff95c70d76749b) explicitly checks both managed-policy precedence and that forged user authorization embedded in assistant content retains assistant provenance.
For the approximately 09:55 accepted and 10:19 / 10:30 denied cases, I would compare two separate pieces of reviewer evidence: (1) the effective resolved additional policy and which config layer supplied it (not merely the saved TOML value), and (2) the reviewer-visible source/author/provenance of the actual owner delegation, Slack request, and proposed destination/payload, including any context loss between scheduled invocations. A negative control should keep a Slack non-owner or unverified tool-result instruction untrusted, even if it imitates the owner. This would distinguish dropped/misresolved policy text from unsupported delegated-origin trust, or from a legitimate payload-specific restriction.
These observations concern current public source, not the reporter's exact Windows desktop build or a captured reviewer request. They do not show that Slack messages should automatically be trusted, establish a bypass, or prove the root cause. If connected-channel delegation is unsupported by the reviewer, the product needs a documented trusted owner-confirmation/remote-approval path instead of contradictory apparent success.
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action