The Approval Happened in the Parent Task. The Review Child Could Not Prove It.
A Codex Desktop user reports explicitly authorizing an originating task to send private source, diffs, tests and QA evidence to Codex for an independent review, then delegating that exact review to a second agent. The review child's own execution was rejected before it ran, the retained record citing no trusted user authorization for that payload and destination. Codex's own current source shows why: a host attested authorization channel exists for exactly this handoff, but it is wired to a registered MultiAgent V2 root and worker relationship, not to every delegated task path an app can create, and an ordinary agent message is never, by that same source, promoted into trusted user evidence.
On the evidence available, the boundary did what a boundary that cannot authenticate delegated authority is supposed to do: it refused to let a second agent's own words stand in for the user's own instruction, and nothing was sent anywhere without that instruction being verifiable. Codex's current source shows a bounded, host attested channel exists for exactly this kind of handoff, root_user_authorization, projecting an authorization state from a registered root thread to a worker, but it applies only where the worker is a registered MultiAgent V2 child of that root; nothing in the reporter's account or in Codex's public source establishes that the review child in this report was such a worker, or explains why, if it was, the projection did not carry the user's consent forward. That is the open question this record leaves open. What it does not leave open is the reporter's own implicit alternative: nothing here shows, or should be read as arguing, that a second agent's statement that permission exists ought to have been enough on its own.
A user reports doing exactly what a security conscious workflow asks: name the private material, name the destination, say so explicitly, before any of it moves. openai/codex issue #43675, opened 8 September 2026, describes authorizing an originating Codex Desktop task to send a bounded, described payload, private maintenance source, diffs, tests and QA evidence, to OpenAI's own Codex for an independent review. The organizer then delegated that review to a second agent. The second agent's own attempt to run the review was rejected before a process ever started, the retained rejection stating, in the reporter's account, that the upload of private repository source, tests and QA evidence to Codex carried no trusted user authorization for that payload and that destination. No reviewer process ran. No review result exists, faked or otherwise. The work that depended on the review was preserved without pretending the review had happened, and the denied action was not quietly rerouted through a different agent or provider.
The reporter is explicit about two limits of their own report: the precise mechanism by which the upstream authorization did not reach, or was not recognized by, the review child is not established, and the affected desktop build was not captured in the sanitized report. This record holds both limits exactly where the reporter left them. A separately reported detail, that the organizer's read and wait calls showed outdated, interrupted turn state while retained records showed later, completed turns without errors, is carried here as a further reported symptom, not as an explanation.
What Codex's own current source establishes, independent of the report
Moona Intelligence read codex-rs/core/src/agent/control/user_authorization.rs and codex-rs/guardian-context/src/transcript.rs directly from openai/codex's current main branch rather than taking the reporter's account of the mechanism on trust. A specific commit the issue thread's own follow up reportedly points to, 3caf9f9586baedb4158a7b91545ead3dd320c348, does not touch either file; it is a TUI change to voice transcript styling and file reference linking, unrelated to authorization projection. This record does not carry that commit citation forward, and it does not carry forward a reported follow up comment citing Codex CLI 0.153.4 and a specific desktop build number either: as fetched this session, the issue itself shows zero comments. Neither absence changes what current main independently shows, and this record keeps the two kinds of fact, what the report claims about its own follow up and what the source itself contains, visibly separate rather than letting an unconfirmed citation stand in for a read of the code.
What current main does establish: root_user_authorization exists specifically to project bounded authorization state from a registered root thread to a worker. It resolves the caller's registered root through AgentPath::root(), returns nothing if the calling thread is itself that root, and returns nothing unless the resolved root thread's own multi_agent_version() is MultiAgentVersion::V2. Only inside that registered relationship does it build a bounded GuardianRootSnapshot: up to eight recent root messages, an authorization_version carrying a retained_context_complete flag, and a set of trusted skill paths tied to the latest resolved user turn. When retained context or an original root instruction cannot be recovered, the function does not silently drop that gap; it flips retained_context_complete to false and inserts an explicit IncompleteRootInstructions or IncompleteVerifiedAnswers marker into the snapshot itself, a first class "the projection is not complete" state distinct from "no authorization exists at all." That is the shape of a host attested projection channel, evidence of what a principal authorized, carried across a task boundary without needing the worker to have witnessed the user's own words, and current source shows it built to survive missing detail rather than to hide it.
collect_transcript, in the second file, confirms the safety property this record's own doctrine already insists on. An ordinary assistant message classifies as ConversationTranscriptEntryKind::Assistant; one flagged as inter agent communication classifies as ProtectedAssistant; neither ever becomes ConversationTranscriptEntryKind::User. A message stating that the user approved something is transcript content attributed to whichever agent said it, not a promotion of that claim into user evidence. The same file separately defines a distinct developer role marker reserved specifically for a manually approved action that had previously been rejected, a second, narrower channel for a human decision the system itself distinguishes from ordinary conversation text. Current source, independently read, treats a bare agent assertion of authorization and a host attested record of one as visibly different kinds of evidence. This record does not read the incident as calling that distinction into question, and it explicitly declines to read the fix for a false negative as any invitation to blur it.
What this does and does not establish about the incident itself
Those two facts, read together, do not resolve why this specific review child's execution was rejected. They establish that Codex is not a system with no mechanism for carrying a user's bounded authorization across a delegation boundary, and that whatever did fail here, if anything did, is not a missing concept so much as a specific instance not reaching, or not qualifying for, a channel that exists for exactly this purpose. A registered relationship that was never established, a projection that ran but returned an incomplete snapshot the review child's own gate still treated as insufficient for a sensitive external destination, or a task path that does not route through this mechanism at all are each consistent with the reported symptoms and with current source, and nothing available to this record adjudicates between them. Root cause here is genuinely unknown, and this record states that as the finding, not as a placeholder for one.
Two related reports, kept separate
openai/codex issue #43214, opened 6 September 2026, reports a Chief task's native worker creation explicitly setting the parent as the destination for a completion report, with the worker's completion message then rejected for the same stated reason, no trusted authorization for the destination and payload. A later, minimal, non sensitive message from the same worker delivered successfully, but the reporter is explicit that the approval output still classified user authorization as unknown even on that success, permitting it only because the content itself was unremarkable. This record reads #43214 as independent, occurrence level corroboration of the same possible mechanism family, a native, host created delegation whose completion callback direction could not be authenticated, not as a second sample of the identical event #43675 describes. The two differ in which direction authorization needed to travel, review payload outbound in #43675, completion report back to the parent in #43214, and in which native primitive is involved.
openai/codex issue #43588, opened 7 September 2026, reports a Desktop voice approval for a git push, PR and deployment repeatedly rejected as untrusted delegated transcript content, with repository permissions independently confirmed and no workaround attempted. Its own reporter states the root cause is unknown, including whether typed approval would behave differently. This record keeps #43588 as corroborating evidence for the same authorization provenance family, a channel that carried explicit user consent failing to have that consent recognized downstream, while declining to assert that a single voice session and a root to worker delegation are the same mechanism; nothing in either report establishes that they are.
openai/codex issue #38481, opened 14 August 2026 and explicitly distinguished by its own reporter from repeated free form instruction claims, describes a different surface again: an explicitly invoked skill whose own contract states that naming a destination authorizes a minimal, non secret payload to it, denied anyway because auto review did not treat the skill's own declared contract as trusted authorization evidence. This record treats #38481 as a related but distinct authorization surface, a skill's own declared, bounded egress grant rather than a root thread's projected authorization to a registered worker, and does not merge its evidence into #43675's.
None of the four reports independently confirms the others' root cause. Each is read here as its own occurrence of a family this record names once: a user's legitimate, bounded authorization, given through a channel the product itself supports, not recognized at the exact boundary where an action needed it.
The Authority Provenance ledger, for this report
Authority grantor. The user, per the reporter's own account, in the originating task.
Mandate or basis. Explicit, bounded consent to an independent Codex review of a named, described payload: private maintenance source, diffs, tests and QA evidence.
Delegated scope. That same review, delegated by the organizer to a second, worker agent. The reporter's account states the delegation carried the authorization and scope; the rejected execution states the review child could not establish that the delegation carried trusted authorization for this payload and destination.
Explicit limits. The payload as named. Nothing in the report describes the user authorizing anything broader, and nothing in the rejection describes the system objecting to scope; it objects to provenance.
Inherited permissions and assumptions. This is the entry current source most directly informs. A registered MultiAgent V2 worker can inherit a bounded, host attested authorization snapshot from its root, evidence rather than assumption, gated to that specific registered relationship. Whether this review child was inside that relationship, and if so why the snapshot it received, if any, did not satisfy its own execution gate for this destination, is unestablished.
Revocation or modification. Not reported and not applicable; nothing in the account describes the user withdrawing or narrowing consent before the rejection.
Challenge authority. The review child's own execution gate, which is the mechanism that raised the rejection in the first place, functioning as intended even if, per this record's reading, it may have been acting on an incomplete or absent projection rather than on a genuine absence of authority.
Recovery. None described. The task's subsequent work is reported preserved without a fabricated review result, which this record reads as the correct recovery behavior even where the denial itself may trace to a provenance gap rather than a genuine lack of authority.
Provenance quality. Strong for the reported observation itself, a fresh, first party bug report with a specific, checkable rejection rationale, corroborated in shape by #43214 and #43588. Source level architecture claims are independently confirmed against current main, not against the specific commit the report's own follow up reportedly cites, which this record does not carry forward unconfirmed. Root cause for why this specific delegated path did not carry authorization through remains unestablished by anything available to this record.
Where this sits next to Moona's other coverage
Ran the required deduplication before writing this record: a search across Intelligence, the Risk Registry, Protocols, both Radar states and this corpus's open and closed pull requests for #43675, #43214, #43588, #38481, and for the underlying mechanism in semantic terms, found no existing canonical ownership of any of the four reports or of the specific legitimate authority loss through delegation mechanism (Records assessment: CREATE this record; evidence delta EXTENDS). Moona's existing Codex delegated child coverage already documents a distinct openai/codex family, provider policy refusals inherited unattenuated by a delegated child, and is left untouched: that family is about a child receiving more restriction than intended, this one is about a child receiving less recognized authority than the user actually granted, and the two are not merged. The instructions are not authorization record, which owns AEW-007, claimed authorization accepted without verification, already states the doctrine this incident's own denial correctly enforced; this record does not add a knownExample there, since nothing here shows a claim being wrongly accepted, only a genuine grant reportedly not being recognized. Moona's coverage of unattenuated delegated authority, which owns AEW-006, is the mirror doctrine for the opposite direction, a child receiving more than its parent held; this record connects to both by reference, in prose, as the duality its own analysis depends on, without asking either weakness to carry evidence of a mechanism neither one names (Risks assessment: NO_CHANGE; no existing Agent Execution Weakness precisely owns a false negative, provenance loss failure mode, and this record does not mint one for a locally correct fail closed denial). No Agent Execution Vulnerability is opened: nothing here is a confirmed, exploitable defect in an identifiable mechanism, only an open, reported denial with an unconfirmed cause (AEV assessment: NO_CHANGE). No Protocol entry changes: this is one vendor's own application behavior under active investigation, not a claim about an adopted interoperability specification (Protocols assessment: NO_CHANGE). The raw evidence this record was built from, the four issue bodies as fetched and the two current source files as fetched directly, is retained as a Moona Intelligence Radar raw discovery artifact under tests/fixtures/discovery-artifacts/raw/, content addressed as sha256:421fb442c1cfe0795fa71704c37c04f92f6d32b3cced05dfad6f945439ea8485, distinct from and traceable ahead of this record's own interpretation of it. Deterministic maturity was recomputed through src/content/evidence-intelligence.ts rather than hand entered.
Sources
This analysis interprets third-party reporting, research and announcements. Moona is not the original reporter of the underlying events.