Skip to content

fix(tauri): restore notifications in remote windows - #641

Open
pascalandr wants to merge 5 commits into
NeuralNomadsAI:devfrom
pascalandr:fix/issue-640-remote-tauri-notifications
Open

fix(tauri): restore notifications in remote windows#641
pascalandr wants to merge 5 commits into
NeuralNomadsAI:devfrom
pascalandr:fix/issue-640-remote-tauri-notifications

Conversation

@pascalandr

@pascalandr pascalandr commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Summary

  • identify remote CodeNomad webviews explicitly as Tauri hosts
  • grant remote-* windows the minimum native notification permissions
  • keep dialogs, opener access, menus, and other desktop privileges restricted to the main window

Cause

Remote windows were marked with the remote window context but not with the Tauri runtime host. The UI therefore selected the Web Notification API inside WebView2, where requesting permission had no effect. Those windows also did not match a Tauri capability that allowed notification plugin commands.

Implementation

The initialization script now sets both runtime host and window context before remote UI scripts run. A dedicated capability permits only permission checks, permission requests, and notification delivery for configured HTTP/HTTPS remote origins.

Validation

  • cargo test --manifest-path packages/tauri-app/src-tauri/Cargo.toml: 85 passed
  • npm run typecheck --workspace @codenomad/ui
  • npm run build:ui
  • git diff --check
  • two independent review rounds: zero findings after least-privilege cleanup

Fixes #640

Mark remote CodeNomad webview windows explicitly as Tauri hosts so notification capability checks use the native plugin instead of the Web Notification API.

Grant remote-* windows only the three notification commands used for permission checks, permission requests, and delivery across configured HTTP and HTTPS server origins. Keep native dialogs and other desktop privileges restricted to the main window.

Add a regression assertion for the injected runtime context. Validated with the UI production build, UI typecheck, all 85 Tauri Rust tests, and independent capability/runtime reviews.

@pascalandr pascalandr left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gatekeeper round 1: 4 findings.

  • P2 security, packages/tauri-app/src-tauri/capabilities/remote-window-notifications.json:6: the capability accepts every HTTP(S) origin while the navigation guard currently treats every localhost/127.0.0.1 URL as internal. A remote-* window can therefore navigate away from its registered origin and retain app-branded notification access.
  • P2 regression, packages/tauri-app/src-tauri/src/main.rs:50: marking remote windows as Tauri changes external URL handling. Provider OAuth now attempts the unauthorized native opener after the async authorization request, then falls back to window.open after user activation may have expired.
  • P2 test gap, packages/tauri-app/src-tauri/src/main.rs:1098: the regression test covers the host marker only. Removing capability registration or required notification permissions still passes.
  • P3 least privilege, packages/tauri-app/src-tauri/capabilities/remote-window-notifications.json:5: local is omitted and defaults to true for a capability intended only for externally hosted remote UI.

The claim that all custom app commands become available was reviewed but excluded: it is pre-existing and not a deterministic regression in this PR.

@pascalandr pascalandr left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gatekeeper round 2: 2 findings.

  • P3 UI consistency, packages/ui/src/lib/settings/behavior-registry.ts:305: remote Tauri windows now satisfy isTauriHost and display the native event transport toggle, but event-transport.ts always forces EventSource for remote windows. The control has no effect and must remain local-only.
  • P2 test gap, packages/tauri-app/src-tauri/src/main.rs:1107: capability registration and permissions are asserted, but remote.urls is not. Narrowing or removing those patterns would restore the notification failure while tests pass.

Origin isolation, local=false, OAuth/browser fallback, Electron behavior and notification permissions otherwise have zero findings.

Pin remote webview HTTP and HTTPS navigation to each configured server origin before granting native notification IPC. Mark the capability remote-only and assert its exact URL, window, registration, and permission contract.

Keep OAuth and external links on the browser popup path in remote Tauri windows, and hide the local-only native event transport setting there. This preserves existing remote behavior while identifying the physical host correctly for notifications.

Validated with all 86 Tauri tests, UI typecheck and production build, rustfmt, diff checks, and three Gatekeeper rounds ending with zero findings.
…ications' into fix/issue-640-remote-tauri-notifications

@pascalandr pascalandr left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gatekeeper round 4: 1 finding.

  • P2 regression coverage, packages/ui/src/lib/external-url.ts:8, provider-manager-modal.tsx:188, behavior-registry.ts:305: the new remote-Tauri compatibility guards are not exercised by tests. Reverting them keeps all Rust/config tests green while breaking OAuth/external links or exposing a local-only setting.

No functional or security findings remain. Add one shared, pure local-Tauri predicate with explicit local/remote host-context tests, then run the final round.

@pascalandr pascalandr left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gatekeeper round 5: 1 finding.

  • P2 CI coverage, packages/ui/src/lib/runtime-env.test.ts:1 and .github/workflows/pr-build.yml:104: the new host-context regression test passes manually but is absent from the workflow's explicit UI test list, so future regressions would not fail PR checks.

No functional, security, runtime, or host-compatibility findings remain.

Centralize local-Tauri detection so native opener usage, OAuth popup behavior, and the native event transport setting share one host-context decision.

Exercise local and remote Tauri plus web and Electron environments, and add the regression test to the PR workflow's explicit runnable UI suite.

Validated with UI typecheck, production build, the exact 173-test workflow command, and Gatekeeper round 6 with zero findings.

@pascalandr pascalandr left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gatekeeper round 6, final commit d846fcd: zero findings.

All findings from rounds 1-5 are resolved: remote origins are pinned, the notification capability is remote-only and least-privilege, OAuth/external links preserve browser behavior, local-only settings stay hidden remotely, capability contracts are asserted, and remote-Tauri guards run in PR CI.

Validation: 86/86 Rust tests, 173/173 runnable UI tests, UI typecheck, production UI build, rustfmt, and diff checks pass. Residual risk is limited to platform-specific WebView2/Windows notification integration; PR CI is currently restarting on the final commit.

@pascalandr

Copy link
Copy Markdown
Contributor Author

@shantur LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Remote window (Tauri) shows 'Permission: Not granted' — no OS notifications when connected to remote server

2 participants