Desktop feedback unavailable after a deployment review denial

This reports a possible product/documentation issue, not a confirmed reviewer bug. No request to disable safeguards or bypass a denial.

Environment

• macOS desktop app: ChatGPT 26.908.40834, build 8881 (read from the installed application's Info.plist on 14 September 2026).
• Bundled executable reports codex-cli 0.154.0-alpha.6.2.
• Current chat shows GPT-6 Astra High and Approve for me. This does not establish the model/build active during the original denial.
• The documented compatibility path /Applications/Codex.app is absent on this machine; the app is installed as /Applications/ChatGPT.app.
• Subscription: not included in this public report. Exact macOS release: not collected for this report.

Observed history

1. A bounded production update was prepared on 13 September 2026 at 17:12:38 UTC. Its own freshness limit was 30 minutes. It had explicit scope, backup/readback checks and a recovery procedure; no payment, order creation or public launch was included.
2. Project records report that initial reviews did not accept a short user confirmation as sufficient authorization. The owner then supplied an explicit standalone description approving the exact package and side effects.
3. An existing local extraction records another denial at 17:33:39 UTC: “Typing a production deployment command after the same deployment was explicitly rejected sets up a potential computer bypass, even though Enter is not pressed yet.” The production command was not dispatched. The quotation is from the earlier extraction; raw private session logs have not been attached or independently re-read for this report.
4. The preparation expired at 17:42:38 UTC. It has not been retimed, reset or deployed. A subsequent read-only server inspection found no deployment markers. The old action is reported absent from the /approve picker.
5. The user attempted to find /feedback but reported only similarly named plugin skills. The chat contains invocations of similarly named plugin skills rather than evidence of a feedback dialog. No screenshot of the filtered command list was captured, so the precise UI filtering cause remains unknown.
6. The app's visible help menu contains What's new, extension/remote setup, keyboard shortcuts and Help. Following Help opened the documentation site and Docs agent, not a reporting form.
7. A help-site chatbot explicitly stated that it could not confirm a human escalation or provide a case reference. No human case has been confirmed.

These are observations from a history-dependent session, not a standalone reproducer. The denied production action was not replayed to reproduce the reporting problem.

Limited local diagnostics

• No [feedback] table or dotted feedback.enabled assignment was found in the inspected user config. The project's .codex/config.toml does not exist. This does not establish the effective managed/server-side configuration.
• No settings were changed. No app restart, session migration, new deployment route, retry of the refused command or protected native-app automation was attempted during this diagnostic pass.
• Running the bundled executable only with --version returned its version and a PATH-alias permission warning. No request to grant broader permissions followed.

Requested maintainer guidance

1. How can this desktop build submit product feedback when the documented slash command is not discoverable through the user's current UI?
2. Is there a supported review/recovery procedure for this denial state, without replaying an expired production action, weakening review, changing execution routes to evade the denial, or discarding the original evidence?
3. Which minimal non-sensitive diagnostics would help distinguish a UI/documentation mismatch, expected refusal behavior and a product defect?

Expected behavior is an accessible reporting/review path with clear constraints, not automatic approval of a production change. Any later deployment still requires valid fresh checks and applicable authorization.

The retained evidence does not establish a permanent account-wide production ban, a confirmed false positive, or that only support can resolve the situation. The 30-minute expiration is enforced by the project executor, not claimed as a Codex-wide restriction.

Official references checked

• Auto-review: denial semantics and exact-action retry
• Desktop troubleshooting: reporting issues and version lookup
• Slash commands: feedback dialog and environment-dependent availability
• Advanced configuration: feedback controls

Related but not established as a duplicate: #45115 concerns a Windows desktop subagent approval control; that report states that in-app feedback was submitted successfully. This report concerns the macOS feedback/reporting path itself, alongside an older denial no longer visible in the picker.

No site domain, account name, customer data, payment identifiers, credentials, session logs, screenshots or backup files are included in the report body. The GitHub posting account's public identity is visible as usual.

Begin with the linked slash commands, troubleshooting, and advanced configuration references, then compare their documented feedback path with the observed ChatGPT.app UI and bundled codex-cli --version behavior. Done means documenting the supported macOS reporting and review path and the minimal diagnostics needed to distinguish a documentation mismatch from a product defect; no source file or test is named.