Codex Desktop on Windows: MCP elicitation approvals lack the actionable notification used for command approvals

What version of the Codex App are you using?

Codex Desktop 26.721.4979.0 (Microsoft Store/AppX, x64).

The affected task recorded embedded Codex core version 0.146.0-alpha.3.1.

What subscription do you have?

Not relevant to the observed approval-routing behaviour.

What platform is your computer?

Windows 25H2, x64, build 26200.8875.

What issue are you seeing?

Blocking approval requests in Codex Desktop are notified differently depending on the internal authorization event type.

During one naturally occurring background task, two approvals occurred in the same task and agent turn:

1. A local command required sandbox escalation. Codex represented it internally as ExecApproval. Windows displayed a prominent Command approval notification with Approve, Approve for session, and Decline actions.
2. Roughly one minute later, an in-app browser-control operation required user authorization. Codex represented it internally as an MCP ResolveElicitation request. The task blocked, but no equivalent actionable Windows notification appeared. The only visible attention state was a green Awaiting approval sidebar tag and a very small orange/red symbol in the Companion bubble.

The affected task remained in the background while another Codex task was selected, so task-selection state does not explain the difference between these two requests.

The Companion bubble also displayed an earlier task-progress message rather than the pending authorization request. Local event correlation showed that this text had been emitted about ten minutes before the approval events and was ordinary progress commentary, not an approval description.

This creates three apparent user-facing states from two underlying authorization events:

| Internal event | Blocking state | User-facing notification |
|---|---|---|
| ExecApproval from a direct command | Yes | Actionable Windows approval notification |
| MCP elicitation from browser control | Yes | Subtle sidebar/Companion attention state only |
| Generic task attention wrapper | Derived from the pending approval | Reuses unrelated earlier progress text |

Both authorization events stopped execution until the user responded. Only one was presented as a clear, actionable approval request.

What steps can reproduce the bug?

This sequence produced the issue during ordinary work. It has not yet been confirmed as a deterministic reproduction:

1. Enable Ask for approval in Codex Desktop.
2. Run a task in the background while another Codex task remains selected.
3. In the background task, execute a local command that requires sandbox escalation.
4. Observe the Windows Command approval notification and approve it.
5. In the same task and turn, invoke an in-app browser-control operation that triggers MCP elicitation, such as making the browser visible and opening a local preview.
6. Observe that the task blocks for the MCP response without showing an equivalent actionable Windows notification.
7. Inspect the sidebar and Companion. The approval may be represented only by a small attention symbol and Awaiting approval tag, while the Companion text describes earlier task progress rather than the authorization request.

The user-facing subtle-notification pattern has occurred more than once. The paired internal comparison above was captured once with sufficient logs to distinguish the two event classes.

What is the expected behavior?

Every authorization event that blocks a task should produce an equally prominent and actionable attention signal when its approval controls are not already visible, regardless of whether the backend event is:

• ExecApproval;
• edit approval;
• MCP elicitation; or
• another user-input event that blocks execution.

For privacy, the desktop notification can use a bounded summary such as Codex is waiting for approval and open the exact pending request inside Codex. It does not need to expose full commands, URLs, local paths, or tool inputs on the Windows lock screen.

The notification and in-app attention state should:

1. identify that authorization is required, rather than looking like ordinary progress or completion;
2. take the user directly to the exact pending request;
3. remain visible until the request is resolved; and
4. never substitute stale task-progress text for the approval description.

Why this matters

• A background task can remain blocked indefinitely without a proportionate notification.
• A green tag can read as healthy or completed rather than requiring intervention.
• The tiny Companion symbol does not explain what action is required.
• Reusing unrelated progress text makes the blocked state look like normal task activity.
• Inconsistent approval visibility weakens the authorization control surface: users cannot reliably tell when Codex is waiting for a consequential decision.

Internal correlation

The local trace distinguishes the requests without relying only on screenshots:

• The command request was a direct shell-tool call with explicit escalation and an ExecApproval decision.
• The browser request was a node_repl tool call that generated an MCP elicitation and was resolved through ResolveElicitation.
• Both occurred in the same task and agent turn under on-request approval mode.
• The displayed progress text preceded the approvals and was not part of either authorization payload.

The evidence establishes separate event classes and different user-facing treatment. It does not establish the precise client-side implementation branch or claim that timing is the root cause.

Likely subsystem:

• Codex Desktop notification dispatch;
• approval-event adapters;
• MCP elicitation routing;
• task attention-state aggregation; and
• Companion notification content selection.

Related issues

Related but not exact duplicates:

• #35379 requests an external notification event for MCP elicitations. This report concerns Codex Desktop's native Windows notification and in-app attention behaviour.
• #20817 requests better sidebar surfacing for tasks awaiting approval. This report adds an event-type distinction and stale-message substitution.
• #33323 concerns inactive approval requests unexpectedly switching the selected task. This report concerns the opposite failure: a background approval can remain too subtle without switching or producing an actionable notification.

Privacy-safe evidence note

Raw screenshots are not attached because they contain account details, task names, unrelated conversation text, branch information, and project context.

Sanitized notification-only crops can be provided. The underlying task, turn, command-call, and MCP request identifiers are retained privately and can be shared with maintainers through an appropriate non-public channel if needed.

Raw local paths, complete command payloads, browsing details, project data, and session logs are intentionally omitted from this public report.