Codex Desktop approval notification opens blank/error route for ambient suggestion command

Open 💬 2 comments Opened Apr 27, 2026 by Fitech
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.422.30944

What subscription do you have?

Enterprise

What platform is your computer?

MacOS / Darwin 25.4.0 arm64 arm

What issue are you seeing?

Codex Desktop repeatedly shows macOS desktop notifications asking for approval to run a command. Clicking the notification opens a blank Codex view with a brief plain-text error that flashes too quickly to read. Approving or denying does not resolve it; restarting Codex causes it to happen again immediately.

This appears to come from background ambient suggestion tasks rather than a visible conversation. The approval notification targets a hidden/stale/inaccessible task route, so the click-through opens an error route instead of the relevant approval UI.

Observed logs:
error Conversation state not found conversationId=<redacted>
[desktop-notifications] show approval conversationId=<redacted> kind=commandExecution requestId=1
[desktop-notifications] notification click open notificationId=approval-2

Sentry breadcrumbs showed repeated 403s:
GET https://chatgpt.com/backend-api/wham/tasks/<redacted> -> 403
GET https://chatgpt.com/backend-api/wham/tasks/<redacted>/turns -> 403

Background task prompt seen in logs:
Generate 0 to 3 ambient suggestions for this local project...

Example requested commands:
pwd
rg --files <project> | sed ... | head -n 200
git log --oneline --decorate -n 15

Expected:
Clicking an approval notification should open the relevant approval UI, or Codex should avoid showing desktop approval notifications for background/ambient tasks whose conversation/task is not accessible in the app.

Privacy:
Local usernames, project paths, task IDs, conversation IDs, and request IDs have been redacted.

What steps can reproduce the bug?

I just open the app and the notifications start coming in.

What is the expected behavior?

I shouldn't get random notifications for approval that don't go anywhere.

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 4 months ago

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

  • #18521
  • #18541
  • #18333

Powered by Codex Action

os369510 · 2 months ago

I’m seeing the same class of issue on Linux/Sway with Mako notifications.

Environment:

  • Codex Desktop package: openai-codex-desktop 26.519.41501-1
  • app-server: 0.137.0
  • runtime bundle seen in logs: 26.601.10930
  • Platform: Linux 7.0.11-arch1-1 x86_64
  • Notification center: Mako under Sway

Observed notification:

  • Codex -> Command approval -> Approval required

But clicking/opening did not show an actionable approval.

Relevant log pattern:

  • Conversation state not found conversationId=...
  • [desktop-notifications] show approval ... kind=commandExecution requestId=...
  • [desktop-notifications] forward show kind=permission notificationId=approval-local-...
  • [desktop-notifications] show notification ... kind=permission

I also saw repeated:

  • [ambient-suggestions-background-refresh] Failed to refresh ambient suggestions ... trigger=background

In one reproduction, background/heartbeat automation log-inspection commands caused several approval notifications (approval-local-10 through approval-local-13) tied to a hidden/background conversation. The commands were read-only (find/rg over Codex logs), and there was no visible approval surface by the time I opened Codex.

Expected behavior:

  • Do not send an OS “Approval required” notification unless human action is actually still required and the target thread/approval can be opened.
  • If the request is auto-reviewed/resolved quickly, suppress or dismiss the OS notification.
  • If the thread/conversation cannot be resolved, do not show a desktop approval notification, or show a clearly non-actionable diagnostic instead.
  • Include command/cwd/source context in the notification or in the click-through target.