Unable to find a scoped approval control for a denied subagent action on Windows desktop

Environment

• Codex desktop on Windows, with automatic approval review enabled.
• Desktop app version: not yet verified.
• Separately, the installed bundled command-line executable reports 0.154.0-alpha.6.2. This is not asserted to be the desktop app version.

Observed problem

A subagent's local file operation was denied before process creation. We could read the subagent's history in a side panel but could not find an accessible control to inspect and approve that exact denial. An attempt to navigate directly to the child instead displayed the parent task. Entering /approve in the parent was delivered as ordinary chat text and did not restart the worker.

This is a report of the observed desktop recovery/discoverability problem, not a claim that approval must override policy or that the reviewer has a proven implementation defect.

Sequence in the affected session

1. The worker originally had a restriction against operations outside its initial local directory allowance.
2. Before the denied execution request, the user approved a narrow exception in the coordinating parent workflow: five files, up to 16 MiB, with all originals retained. The owning parent recovered the original user approval and reconciled the scope before the execution request.
3. The original worker submitted the prepared local copy/restore/catalog operation. Automatic review rejected it before process creation, citing the earlier restriction. We cannot establish whether the review omitted or interpreted the later authorization differently.
4. On Windows desktop, the child was accessible through the parent's Subagents detail panel. Direct navigation to the child displayed the parent rather than a separately writable child conversation.
5. We could not find a matching approval control in the inspected menus. We tried entering /approve in the parent; it was treated as ordinary text, not an action-specific permission grant. This describes an attempted command, not a verified working desktop command.
6. The operation remained stopped. No alternate executor, permission-setting change, or workaround was used after this denial.
7. In-app feedback was submitted successfully. Its identifier can be supplied through a private support channel if required.

These are steps observed in a history-dependent session. We have not established a standalone reproducer or reproduced the problem in a fresh task.

Expected behavior / clarification requested

Please provide a supported, discoverable way to inspect a denied child action and, where allowed, approve only that exact scoped action. If this is unsupported for subagents or intentionally non-overridable, please show that limitation and its supported recovery path clearly in the desktop interface.

We are not requesting full filesystem access, removal of automatic review, or a guarantee that user approval forces execution.

Related report and privacy

Related but not established as a duplicate: #43660 concerns a Linux CLI action rejected after an actual action-specific approval. Our observed problem is that the matching approval control could not be reached in the Windows desktop subagent workflow.

No project names, strategy details, internal paths, source, logs, screenshots, account information, credentials, or private task/feedback identifiers are included in this public report.

Start by reproducing the Windows desktop subagent flow and inspecting the parent's Subagents detail panel after a child action is denied. The issue is done when the denied child action has a discoverable, exact-scope approval path, or the interface clearly explains that approval is unsupported and shows the supported recovery path.