[Release] v1.2.5

[Power-Maverick]

Summary

This pull request introduces several improvements and new features to the desktop app, including enhanced headless tool logging, private marketplace configuration documentation, and dependency updates. It also refines the release workflow for Windows installers.

Type of change

• New feature
• Bug fix
• Refactor (no functional change)
• Documentation
• Chore / maintenance (dependency update, build, config)
• Test addition / improvement

Changes

New Features & Documentation

• Added a comprehensive PRIVATE_MARKETPLACE_CONFIGURATION.md guide explaining how to configure and host a private marketplace, including Azure Blob Storage integration and packaging instructions.
• Enhanced headless tool logging: headless invocations now capture tool messages via context.logger, which are stored with the job and surfaced in the MCP Server UI. The documentation describes how to use this logger and how logs are displayed live in the server page. [1] [2]

Build & Release Workflow Improvements

• Refactored the Windows packaging step in .github/workflows/nightly-release.yml and .github/workflows/prod-release.yml to ensure the "Package installers from signed directory" step runs after generating app-update.yml and before signing with Azure Trusted Signing. This fixes the step ordering for Windows builds. [1] [2] [3] [4]

Dependency Updates

• Added @sentry/electron as a new dependency for error tracking. [1] [2]
• Updated and reordered playwright in package.json for consistency. [1] [2]
• Bumped app version to 1.2.5 in package.json.
• Updated pnpm-lock.yaml with new dependencies, including OpenTelemetry packages and APM JS Collab utilities. [1] [2]

Architecture checklist

Packages (types & validation)

• Not applicable — no changes to packages/

If you did change a package:

• @pptb/types (types): type definitions updated and version bumped in packages/types/package.json
• @pptb/validate (validation): validation rules updated and version bumped in packages/validation/package.json

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:

Screenshots / recordings

Breaking changes

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

Reviewer notes

• 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

[Copilot]

Pull request overview

Copilot reviewed 70 out of 76 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

Suppressed comments (7)

src/renderer/modals/cspException/controller.ts:33

• Avoid using console.warn in shipped modal controller script. This repo’s logging standard is to avoid console.* in production code; here it will run in the modal BrowserWindow and could leak noisy output.
  vite.config.ts:34
• Vite config currently logs environment-status messages via console.log/warn. This adds noise to builds/CI and conflicts with the repo guideline to avoid console.* in production code (even though this is build-time code). Consider removing these logs and relying on runtime validation / explicit errors where needed.
  src/main/managers/headlessToolInvocationManager.ts:199
• Failure path calls notifyJobChanged() immediately after appendLog(). appendLog() already notifies, so this doubles job-change notifications unnecessarily.

            this.jobs.set(jobId, failed);
            this.appendLog(jobId, "error", failed.error);
            this.notifyJobChanged(jobId);
        }

src/common/logger.ts:7

• This change routes all app logging through sentryHelper, but sentryHelper currently writes to console.* (e.g. src/common/sentryHelper.ts:343, 412-462). The repo’s logging standard explicitly forbids console.* in production code, so this effectively reintroduces console logging across the app.

 * All application logging flows through this module. Log calls are forwarded to
 * sentryHelper which routes them through Sentry structured logging (when a DSN is
 * configured) and always mirrors output to the console.
 *

src/main/managers/headlessToolInvocationManager.ts:182

• runJob() calls notifyJobChanged() immediately after appendLog(). Since appendLog() already calls notifyJobChanged(), this results in duplicate job-change notifications (extra IPC/UI refresh).

This issue also appears on line 196 of the same file.

            this.jobs.set(jobId, completed);
            this.appendLog(jobId, "info", "completed");
            this.notifyJobChanged(jobId);

src/renderer/modals/sentryConsent/view.ts:91

• The Privacy Policy link uses target="_blank" without rel="noopener noreferrer". Adding rel avoids potential window.opener issues when opening external pages.
  src/main/index.ts:495
• Duplicate ipcMain.removeHandler calls for GET_JOB_STATUS and CLEAR_LOGS are present twice, which is redundant and makes handler cleanup harder to maintain.

        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_JOB_STATUS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.CLEAR_LOGS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_JOB_STATUS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.CLEAR_LOGS);

[Copilot]

Pull request overview

Copilot reviewed 69 out of 75 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

Suppressed comments (10)

src/main/managers/headlessToolInvocationManager.ts:198

• runJob() calls notifyJobChanged() immediately after appendLog(), but appendLog() already notifies. This results in duplicate update events for the same transition (failed).

            this.appendLog(jobId, "error", failed.error);
            this.notifyJobChanged(jobId);

src/renderer/modals/cspException/controller.ts:33

• Avoid console.* in production code paths (project logging guidelines). This modal controller script should fail silently when modalBridge is unavailable rather than emitting console warnings.
  src/common/sentryHelper.ts:414
• Project guidelines prohibit console.* in production code. logInfo() currently mirrors to console unconditionally; gate this to development-only (or remove) to avoid production console output.

    // eslint-disable-next-line no-console
    console.info("[INFO]", message, data || "");

src/common/sentryHelper.ts:430

• Project guidelines prohibit console.* in production code. logWarn() currently mirrors to console unconditionally; gate this to development-only (or remove) to avoid production console output.

    // eslint-disable-next-line no-console
    console.warn("[WARN]", message, data || "");

src/common/sentryHelper.ts:446

• Project guidelines prohibit console.* in production code. logError() currently mirrors to console unconditionally; gate this to development-only (or remove) to avoid production console output.

    // eslint-disable-next-line no-console
    console.error("[ERROR]", message, data || "");

src/common/sentryHelper.ts:462

• Project guidelines prohibit console.* in production code. logFatal() currently mirrors to console unconditionally; gate this to development-only (or remove) to avoid production console output.

    // eslint-disable-next-line no-console
    console.error("[FATAL]", message, data || "");

src/main/index.ts:495

• Duplicate ipcMain.removeHandler calls for GET_JOB_STATUS and CLEAR_LOGS. This is redundant and makes it harder to reason about teardown coverage.

        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_JOB_STATUS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.CLEAR_LOGS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_JOB_STATUS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.CLEAR_LOGS);

src/main/managers/settingsManager.ts:109

• normalizeMarketplaceSources() defaults enabled based on source.type, but type is being normalized on the same object literal. If an entry omits type and enabled, this will default to false even for the built-in marketplace (until later logic patches it), and can also mis-default other entries. Default should be derived from the normalized type/id.

            enabled: typeof source.enabled === "boolean" ? source.enabled : source.type === "builtin" ? true : false,

src/main/managers/headlessToolInvocationManager.ts:182

• runJob() calls notifyJobChanged() immediately after appendLog(), but appendLog() already notifies. This results in duplicate update events for the same transition (completed).

This issue also appears on line 197 of the same file.

            this.appendLog(jobId, "info", "completed");
            this.notifyJobChanged(jobId);

src/common/sentryHelper.ts:343

• Project guidelines prohibit console.* in production code. logCheckpoint() currently writes to console unconditionally; this should be gated to development-only (or removed) so production runs don't emit console output.

This issue also appears in the following locations of the same file:

• line 413
• line 429
• line 445
• line 461

export function logCheckpoint(checkpoint: string, data?: Record<string, unknown>): void {
    // eslint-disable-next-line no-console
    console.log("[Checkpoint]", checkpoint, data ? JSON.stringify(data, null, 2) : "");

[Copilot]

Pull request overview

Copilot reviewed 69 out of 75 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

Suppressed comments (5)

Previously missed (5) — in code that hasn't changed since the last review.

src/renderer/modals/cspException/controller.ts:33

• This controller script uses console.warn(...). The repo’s logging approach appears to be moving to the centralized logger/Sentry helper, and this exact console warning is duplicated across multiple modal controllers. Consider removing the console call (or routing through the centralized logging path) to keep production output consistent.
  src/main/index.ts:495
• Duplicate ipcMain.removeHandler calls for GET_JOB_STATUS and CLEAR_LOGS are redundant and make teardown harder to reason about. Remove the duplicate lines so each channel is only removed once.

        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_CLIENT_CONFIG_STATUSES);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_JOB_STATUS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.CLEAR_LOGS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_JOB_STATUS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.CLEAR_LOGS);

src/main/managers/settingsManager.ts:109

• normalizeMarketplaceSources() computes a fallback type for sources, but the enabled default is based on source.type (the pre-normalized value). If type is omitted in stored settings, this can incorrectly default enabled to false (including for the built-in source when a private source exists). Default enabled based on the effective type.

            enabled: typeof source.enabled === "boolean" ? source.enabled : source.type === "builtin" ? true : false,

src/main/managers/settingsManager.ts:335

• CSP consent records persisted from older versions will not have the new seenOptional field, but getCspConsents() returns the raw store value. Because CspConsentRecord.seenOptional is now required, this can break consumers that iterate all consents (e.g. consent review UI) on upgrade. Consider normalizing/migrating consents on read (fallback seenOptional to optional).

    grantCspConsent(toolId: string, requiredDomains: string[] = [], approvedOptionalDomains: string[] = [], seenOptionalDomains: string[] = []): void {
        const cspConsents = this.store.get("cspConsents") || {};
        cspConsents[toolId] = { allowed: true, required: requiredDomains, optional: approvedOptionalDomains, seenOptional: seenOptionalDomains };
        this.store.set("cspConsents", cspConsents);

src/main/managers/headlessToolInvocationManager.ts:182

• runJob() calls appendLog(...), which already calls notifyJobChanged(). The extra notifyJobChanged() calls after appendLog() will double-fire job update events (and likely double IPC updates) for completed/failed jobs. Drop the redundant notifications so each state change only emits once.

            this.jobs.set(jobId, completed);
            this.appendLog(jobId, "info", "completed");
            this.notifyJobChanged(jobId);

[Copilot]

Pull request overview

Copilot reviewed 71 out of 77 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

Suppressed comments (4)

Previously missed (4) — in code that hasn't changed since the last review.

src/main/index.ts:496

• Duplicate ipcMain.removeHandler calls for MCP_SERVER_CHANNELS.GET_JOB_STATUS and MCP_SERVER_CHANNELS.CLEAR_LOGS. This is redundant and makes it easier for the handler list to drift over time.

        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_CLIENT_CONFIG_STATUSES);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_JOB_STATUS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.CLEAR_LOGS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_JOB_STATUS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.CLEAR_LOGS);

src/renderer/modules/cspExceptionModal.ts:99

• openCspConsentManagementModal is documented to return null when cancelled, but closing the modal currently rejects the promise. In the consent review flow this gets caught as an error and triggers a "Consent Update Failed" notification even though the user just dismissed the dialog.
  src/main/managers/headlessToolInvocationManager.ts:184
• runJob() calls appendLog(), which already notifies listeners via notifyJobChanged(), but then also calls notifyJobChanged() again in both the completed and failed paths. This can cause redundant renderer refreshes/IPC updates for every job completion/failure.

            this.jobs.set(jobId, completed);
            this.appendLog(jobId, "info", "completed");
            this.notifyJobChanged(jobId);
        } catch (error) {
            const failed = this.jobs.get(jobId);

src/common/logger.ts:6

• The header comment states logs are "always" mirrored to the console, and logger.ts forwards everything to sentryHelper where logInfo/logWarn/logError/logCheckpoint call console.* even in production. This conflicts with the repo guideline to avoid console.* in production code; consider mirroring only in development or routing entirely through Sentry.

 * All application logging flows through this module. Log calls are forwarded to
 * sentryHelper which routes them through Sentry structured logging (when a DSN is
 * configured) and always mirrors output to the console.

[Copilot]

Pull request overview

Copilot reviewed 82 out of 88 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

Suppressed comments (5)

Previously missed (5) — in code that hasn't changed since the last review.

src/renderer/modals/cspException/controller.ts:32

• console.warn is used in the injected modal controller script. This repo’s guidelines prohibit console.* usage in production code; this same pattern exists in several modal controllers and should be replaced/removed consistently.
  src/main/index.ts:495
• Duplicate ipcMain.removeHandler calls for MCP_SERVER_CHANNELS.GET_JOB_STATUS and MCP_SERVER_CHANNELS.CLEAR_LOGS are present back-to-back. This is redundant and makes the teardown list harder to maintain.

        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_JOB_STATUS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.CLEAR_LOGS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_JOB_STATUS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.CLEAR_LOGS);

src/renderer/modals/mcpInvocationDetails/view.ts:74

• Status mapping does not account for AgentInvocationLogEntry.outcome === "in-progress" (it currently falls back to "pending"). This causes active invocations to display the wrong status badge when no HeadlessJobDetails are available.
  src/main/managers/headlessToolInvocationManager.ts:182
• runJob() triggers duplicate job-change notifications on completion/failure: appendLog() already calls notifyJobChanged(), but runJob() calls notifyJobChanged() again immediately afterward. This can cause double UI refresh/events per state change.
  src/renderer/modules/cspExceptionModal.ts:99
• openCspConsentManagementModal() rejects the promise when the modal is closed via the window close button. Callers (e.g. consent review action handler) treat cancel as a non-error and will currently show an error notification/log for a user cancel. The JSDoc also says it returns null when cancelled.

[Copilot]

Pull request overview

Copilot reviewed 82 out of 88 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

Suppressed comments (6)

Previously missed (5) — in code that hasn't changed since the last review.

src/renderer/modals/cspException/controller.ts:32

• This controller script uses console.warn in production code. Repo logging guidance says to avoid console.* and route logs through Sentry/central logging instead; the same console.warn pattern appears in multiple modal controllers.
  src/main/index.ts:495
• Duplicate ipcMain.removeHandler calls for MCP job-status/log channels are present. This is redundant and makes the teardown list harder to audit.

        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_CLIENT_CONFIG_STATUSES);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_JOB_STATUS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.CLEAR_LOGS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_JOB_STATUS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.CLEAR_LOGS);

src/main/managers/settingsManager.ts:110

• normalizeMarketplaceSources() infers a default source.type, but the default-enabled logic still checks source.type (the original value). If a stored source is missing type, this can incorrectly default enabled=false even when the inferred type is "builtin" (and can unexpectedly disable the built-in marketplace when a private source exists).
  src/renderer/modals/sentryConsent/view.ts:91
• External link opens with target="_blank" but is missing rel="noopener noreferrer", which can allow reverse-tabnabbing. The same pattern also exists in other renderer HTML generation (e.g. src/renderer/modules/initialization.ts:698).
  src/main/managers/headlessToolInvocationManager.ts:182
• runJob() calls appendLog(), which already notifies listeners via notifyJobChanged(). The extra notifyJobChanged(jobId) here causes duplicate job-updated events for the completion transition.

This issue also appears on line 196 of the same file.

src/main/managers/headlessToolInvocationManager.ts:198

• runJob() calls appendLog(), which already notifies listeners via notifyJobChanged(). The extra notifyJobChanged(jobId) here causes duplicate job-updated events for the failure transition.

[Copilot]

Pull request overview

Copilot reviewed 83 out of 89 changed files in this pull request and generated no new comments.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

Suppressed comments (3)

Previously missed (3) — in code that hasn't changed since the last review.

src/main/index.ts:495

• ipcMain.removeHandler is called twice for MCP_SERVER_CHANNELS.GET_JOB_STATUS and MCP_SERVER_CHANNELS.CLEAR_LOGS, which is redundant and makes it easier to introduce mismatches when this list changes.

        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_CLIENT_CONFIG_STATUSES);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_JOB_STATUS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.CLEAR_LOGS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.GET_JOB_STATUS);
        ipcMain.removeHandler(MCP_SERVER_CHANNELS.CLEAR_LOGS);

src/main/managers/headlessToolInvocationManager.ts:198

• appendLog() already calls notifyJobChanged(), so the explicit notifyJobChanged(jobId) after appendLog() causes duplicate “job updated” notifications on both the completed and failed paths.
  src/renderer/modals/sentryConsent/view.ts:91
• Links opened with target="_blank" should include rel="noopener noreferrer" to prevent reverse-tabnabbing and ensure the new page cannot access window.opener. The repo already uses this pattern elsewhere (e.g. src/renderer/modals/cspException/view.ts:512).