[Feat]: MCP approval attention controls and localized notifications

[Stiwar0098]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the feature has not already been requested

🚀 Feature Proposal

Add MCP approval attention controls so Tabularis can actively surface pending approval requests instead of silently waiting in the background. When a new MCP approval arrives, the app should be able to bring the main window to the foreground, temporarily force always-on-top, request OS-level user attention, send a native notification, and play a short alert sound.

This also adds two persisted safety settings under the MCP safety section:

• mcpApprovalAlwaysOnTop (default rue)
• mcpApprovalNotifySound (default rue)

The approval gate should wait until the application language is settled before triggering modal copy and notification copy, so users see localized text consistently. If language application hangs, the UI should fail open instead of blocking approvals indefinitely.

Motivation

Today MCP approvals can be easy to miss if Tabularis is behind another window or if startup language hydration is still in progress. That creates a bad AI approval workflow because the MCP client is waiting while the user has no clear signal that action is required.

These changes improve discoverability and safety by making approval prompts visible and configurable, while also protecting against regressions where temporary window state is not restored or localization races show inconsistent copy.

Example

1. A Claude/Cursor/OpenCode MCP client sends a query that requires approval.
2. Tabularis shows the approval modal.
3. If enabled, Tabularis:
   • brings the main window to the front,
   • temporarily makes it top-most,
   • requests OS-level user attention,
   • sends a native notification,
   • plays a short alert sound.
4. After the approval is handled, the previous window state is restored.
5. Users can disable either always-on-top attention or notification/sound from MCP Safety settings.

Implementation notes covered by the branch:

• Tauri notification plugin integration
• extra Tauri window capabilities for attention/focus/minimize/show/hide behavior
• frontend utility for window snapshot/restore and alert playback
• tests for attention behavior, language-settlement timing, and notification/sound handling

[rpelevin]

The attention controls make sense, but I would keep a hard boundary between "surface the pending approval" and "change the approval state."

The approval request itself should remain a durable pending decision until the user approves, denies, cancels, or the request expires. Window focus, always-on-top, notifications, sounds, and localization fallback should only affect discoverability.

State shape worth testing:

• approval request id;
• MCP client identity;
• server/tool identity;
• canonical args digest;
• risk label;
• created timestamp;
• attention attempts emitted;
• current UI language used for prompt copy;
• decision state: pending, approved, denied, expired, cancelled;
• restored window state after dismissal.

I would be careful with "fail open" if language application hangs. For UI copy, fallback to a default language is fine. For execution, the tool should stay blocked until a real decision or expiry. Otherwise a localization race could accidentally become an execution bypass.

Acceptance tests:

• pending approval remains pending after notification/focus attempts;
• always-on-top is restored after approve, deny, and close;
• notification click reopens the same pending approval id;
• language timeout shows fallback copy but does not auto-approve;
• duplicate attention events do not create duplicate approval requests;
• expired approval cannot be approved from a stale notification.

That keeps the UX improvement strong without weakening the MCP safety boundary.

[debba]

Very valuable feedbacks @Stiwar0098 and @rpelevin !
Would you be interested in opening a PR?

[rpelevin]

Thanks — I would scope it narrowly before opening anything.

The first useful PR probably should not try to build the full approval UX. I would make the first pass a small safety-boundary / test-shape change around one invariant:

attention mechanisms can surface an existing pending approval, but they cannot create, approve, deny, expire, or otherwise mutate the approval decision.

The acceptance tests I would start from are:

• notification/focus/always-on-top attempts leave the same approval request in pending;
• clicking a notification reopens the same pending approval id, not a new request;
• language fallback can change prompt copy, but cannot auto-approve or fail open;
• duplicate attention events do not create duplicate approval requests;
• an expired approval cannot be approved from a stale notification;
• approve, deny, cancel, close, and expiry all restore window state cleanly.

That would keep the PR small and make the safety boundary clear before touching broader UI behavior.

If that direction fits, the only thing I would want clarified first is the preferred module/file boundary for the initial change: should this start as tests/spec wording around the approval state model, or as a small implementation change in the attention/localization path?