[Feature] Re-trigger CSP consent when tool adds new permissions since last approval

[Copilot]

One-time CSP consent meant a tool update silently gaining new network permissions without the user ever seeing them. This adds re-consent detection: on each tool launch, current permissions are diffed against what was stored at last consent, and if new domains appear the modal fires again showing only the delta.

Summary

When a tool update adds new CSP permissions, the app now detects the change at launch time and re-shows the consent modal highlighting only the new permissions alongside previously approved ones as read-only context. Declining re-consent preserves the existing consent record unchanged and cancels the launch.

Closes #157

Type of change

• New feature

Changes

• src/common/types/settings.ts — Added seenOptional: string[] to CspConsentRecord. Tracks all optional domains presented to the user (approved or declined), so previously-declined optional domains aren't treated as new on the next launch.
• src/main/managers/settingsManager.ts — grantCspConsent accepts a 4th seenOptionalDomains parameter and persists it.
• src/main/index.ts / src/main/preload.ts — IPC handler and preload API updated to forward seenOptionalDomains.
• src/renderer/modals/cspException/view.ts — New CspReconsentContext interface; view renders in two modes:
  • Initial consent (existing): all Required / Optional entries with checkboxes.
  • Re-consent: New Required + New Optional (actionable) + Previously Approved (read-only, dimmed).
• src/renderer/modules/cspExceptionModal.ts — openCspExceptionModal accepts optional CspReconsentContext; re-exported for callers.
• src/renderer/modules/toolManagement.ts — After finding an existing consent record, diffs current domain sets against required and seenOptional. New domains trigger re-consent modal. On accept, merges new domains into stored sets. On decline, leaves consent unchanged and cancels launch.

Re-consent detection logic:

// "new" = present now but absent at last consent
const newRequired = [...currentRequiredSet].filter(d => !previousRequired.includes(d));
const newOptional  = [...currentOptionalSet].filter(d => !previousSeenOptional.includes(d));

if (newRequired.length > 0 || newOptional.length > 0) {
    // open re-consent modal — decline keeps old record intact
}

Architecture checklist

Packages (types & validation)

• Not applicable — no changes to packages/

Code quality

• pnpm run typecheck passes with 0 errors (warnings are acceptable)
• pnpm run lint passes with 0 errors (warnings are acceptable)
• pnpm run build completes successfully

Testing

• pnpm run test:unit passes (for changes to src/main/, src/common/, or src/renderer/ utilities)
• pnpm run test:e2e passes (for UI / navigation / end-to-end flows)
• Manually tested in the running app (pnpm run dev)

Scenario tested:

3 new unit tests added to tests/unit/main/managers/settingsManager.test.ts covering seenOptional persistence, default-to-empty-array behaviour, and full record shape via getCspConsents(). All 168 unit tests pass.

Breaking changes

• No breaking changes
• Yes — describe impact and migration path below:

grantCspConsent IPC and preload API gains a 4th optional parameter seenOptionalDomains?: string[]. Existing callers that omit it default to []. Existing stored CspConsentRecord objects without seenOptional are handled gracefully: the re-consent logic falls back to the stored optional list (seenOptional ?? optional), which means users with prior consents will see a one-time re-prompt if the tool has optional permissions they previously declined — a safe and intentional UX trade-off for the migration.

Reviewer notes

• The backward-compat fallback (seenOptional ?? optional) means users upgrading from old consent records may see the re-consent modal once for optional domains they had declined before. This is intentional and bounded to a single extra prompt.
• previouslyApprovedRequired + previouslyApprovedOptional in the re-consent context are the user-approved subsets, not the full seen set — only the "Previously Approved" section in the UI shows domains the user actually allowed.
• I have added appropriate unit and/or e2e tests for this change
• I have resolved all GitHub Copilot review comments
• I have followed the guidelines in CONTRIBUTING.md

• Fixes [Feature]: Trigger CSP reauth to the user if the tool has changes since last release #157

[github-actions]

❌ PR Checklist — Action Required

The following items must be completed before this PR can be merged:

• Testing — all checkboxes must be ticked before merging
• Reviewer notes — all checkboxes must be ticked before merging

---

🔴 breaking-change label applied

[Power-Maverick]

@copilot build failed

Error: src/renderer/modules/toolManagement.ts(506,108): error TS2554: Expected 1-3 arguments, but got 4.
Error: src/renderer/modules/toolManagement.ts(568,104): error TS2554: Expected 1-3 arguments, but got 4.
 ELIFECYCLE  Command failed with exit code 2.
 ELIFECYCLE  Command failed with exit code 2.
Error: Process completed with exit code 2.

[Copilot]

@copilot build failed

...

Fixed in the latest commit. The grantCspConsent type definition in src/common/types/api.ts was missing the 4th seenOptionalDomains?: string[] parameter — the preload implementation and call sites had it, but the shared ToolboxAPI interface hadn't been updated. The type now matches everywhere and TS2554 is resolved.

[github-actions]

Bundle Size Report 📦

Bundle	Size
Main Process	1.32 MB
Renderer JS	615.31 KB
Renderer CSS	101.13 KB
Total	2.02 MB

Bundle Analysis Reports

The detailed bundle analysis reports are available in the workflow artifacts:

• 📊 Main Process: stats-main.html
• 📊 Renderer Process: stats-renderer.html

Download the artifacts from the workflow run to view interactive visualizations.

---

Bundle size tracking is now active! This helps prevent bundle bloat.

[Power-Maverick]

@copilot whats the expected change in the Supabase when update for a tool is processed?

[Copilot]

@copilot whats the expected change in the Supabase when update for a tool is processed?

No changes to Supabase are expected — the desktop app only reads from Supabase, never writes tool metadata back to it.

Here's the full flow when a tool update is processed:

1. Tool publisher side (Supabase): The publisher updates the tools table row — bumping version and updating csp_exceptions to include any new domains. This happens outside the desktop app entirely.

2. Update detection (checkForUpdates): The app compares registryTool.version (from Supabase) against the locally installed version. If they differ, an update is available.

3. Update install (updateTool → registryManager.installTool): The app re-installs the npm package. After installation, the new manifest (including the updated cspExceptions from the tool's package.json / Supabase record) is stored locally.

4. Next launch — CSP re-consent (this PR): When the user opens the updated tool, toolManagement.ts reads tool.cspExceptions from the locally-stored manifest and diffs it against the consent record in electron-store. If new domains appear in cspExceptions that weren't present at last consent, the re-consent modal fires.

So Supabase is the source of truth for what cspExceptions a tool declares, and the local electron-store consent record is the source of truth for what the user has approved. The re-consent logic bridges the two on each launch.