[wispr-flow] Add Windows Support

[YONN2222]

Description

• Added Windows support for the extension, including Windows platform metadata and platform-specific handling for Wispr Flow detection, database path resolution, and app launching.
• Improved transcript app icon resolution on Windows by mapping installed apps and registry entries.
• Hardened database write operations by using async writes, awaiting UI refreshes after mutations, and adding a node:sqlite fallback with better error handling.
• Updated dependencies to the latest versions so Windows works.

Checklist

• I read the extension guidelines
• I read the documentation about publishing
• I ran npm run build and tested this distribution build in Raycast
• I checked that files in the assets folder are used by the extension itself
• I checked that assets used by the README are placed outside of the metadata folder

Issues

Closing: #26976

[raycastbot]

Thank you for your contribution! 🎉

🔔 @05bmckay @cv087 you might want to have a look.

You can use this guide to learn how to check out the Pull Request locally in order to test it.

📋 Quick checkout commands

BRANCH="ext/wispr-flow"
FORK_URL="https://github.com/YONN2222/raycast-extensions.git"
EXTENSION_NAME="wispr-flow"
REPO_NAME="raycast-extensions"

git clone -n --depth=1 --filter=tree:0 -b $BRANCH $FORK_URL
cd $REPO_NAME
git sparse-checkout set --no-cone "extensions/$EXTENSION_NAME"
git checkout
cd "extensions/$EXTENSION_NAME"
npm install && npm run dev

We're currently experiencing a high volume of incoming requests. As a result, the initial review may take up to 10-15 business days.

[greptile-apps]

Greptile Summary

This PR adds Windows platform support to the wispr-flow extension, introducing a PlatformAdapter abstraction, Windows-specific database path and app-detection logic, a PowerShell registry map for source-app icons, and an async writeSQL helper with a node:sqlite / sqlite3 CLI fallback.

• P1 – "Open Wispr Flow" button hidden on Windows (both views): search-transcripts.tsx resolves wisprFlowPath via appPathMap.get(\"com.electron.wispr-flow\"), but on Windows the map is keyed by lowercased exe names, so that key never matches. manage-dictionary.tsx goes further and only uses bundleId === WISPR_FLOW_BUNDLE_ID, with no Windows fallback at all — the action disappears on Windows in both views.
• P2 – Sync CLI fallback in writeSQL: The sqlite3 fallback path uses execFileSync, blocking the event loop despite the PR's stated goal of async writes.

Confidence Score: 4/5

Core read/write operations work correctly on both platforms, but two P1 findings cause the "Open Wispr Flow" convenience action to silently disappear on Windows in both view commands.

The two P1 issues both affect the same feature (opening Wispr Flow from within a view command on Windows), which is a real behavioral regression introduced by this PR. Core dictionary and transcript functionality is unaffected. Score is 4 rather than lower because no data loss or security risk is present.

extensions/wispr-flow/src/search-transcripts.tsx (line 325) and extensions/wispr-flow/src/manage-dictionary.tsx (lines 208–213) — both need a Windows-aware Wispr Flow path lookup.

Vulnerabilities

• The PowerShell script in getWindowsAppPathMap (platform.ts) reads only from hardcoded registry paths with no user-supplied input, so there is no injection risk.
• writeSQL constructs raw SQL strings; callers use escapeSQL/validateUUID helpers consistently, limiting SQL injection surface.
• No secrets or credentials are handled or exposed.
• No other security concerns identified.

Important Files Changed

Filename	Overview
extensions/wispr-flow/src/platform.ts	New file introducing macOS/Windows platform adapters; Windows detection and db-path resolution look reasonable, but the PowerShell registry map and getWindowsAppPathMap are only consumed for source-app icons — Wispr Flow's own exe is not included in the lookup.
extensions/wispr-flow/src/db.ts	Adds async writeSQL with node:sqlite primary path and sqlite3 CLI fallback; fallback incorrectly uses execFileSync (blocking), contradicting the stated goal of async writes.
extensions/wispr-flow/src/search-transcripts.tsx	Adds Windows exe-name → path map for source app icons; however, the Wispr Flow path is still resolved via bundle ID ("com.electron.wispr-flow") which will miss on Windows, hiding the "Open Wispr Flow" action.
extensions/wispr-flow/src/manage-dictionary.tsx	Uses bundleId === WISPR_FLOW_BUNDLE_ID to resolve the Wispr Flow path for the action panel; this macOS-only approach will silently fail on Windows, so the "Open Wispr Flow" action is always missing on Windows.
extensions/wispr-flow/src/open-app.ts	Simplified to use the shared openWisprFlow helper; clean and correct.
extensions/wispr-flow/package.json	Added "Windows" to platforms with correct capitalization; dependency versions bumped to latest; all dependencies are used in source files.
extensions/wispr-flow/CHANGELOG.md	New entry correctly placed at the top with {PR_MERGE_DATE} placeholder; descending version order maintained.

Comments Outside Diff (1)

1. extensions/wispr-flow/src/manage-dictionary.tsx, line 208-213 (link)

   "Open Wispr Flow" button unreachable on Windows

   wisprFlowPath is resolved by matching app.bundleId === WISPR_FLOW_BUNDLE_ID — a macOS-only concept. On Windows, getApplications() returns apps identified by exe path, not a macOS-style bundle ID, so this lookup will always return undefined and the "Open Wispr Flow" action panel item will never render.

   search-transcripts.tsx correctly builds a Windows exe-name → path map for source apps. The same approach (or using appPathMap.get("wispr flow") from a shared path map) is needed here to surface the Wispr Flow path on Windows.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: extensions/wispr-flow/src/manage-dictionary.tsx
   Line: 208-213
   
   Comment:
   **"Open Wispr Flow" button unreachable on Windows**
   
   `wisprFlowPath` is resolved by matching `app.bundleId === WISPR_FLOW_BUNDLE_ID` — a macOS-only concept. On Windows, `getApplications()` returns apps identified by exe path, not a macOS-style bundle ID, so this lookup will always return `undefined` and the "Open Wispr Flow" action panel item will never render.
   
   `search-transcripts.tsx` correctly builds a Windows exe-name → path map for source apps. The same approach (or using `appPathMap.get("wispr flow")` from a shared path map) is needed here to surface the Wispr Flow path on Windows.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

Prompt To Fix All With AI

This is a comment left during a code review.
Path: extensions/wispr-flow/src/manage-dictionary.tsx
Line: 208-213

Comment:
**"Open Wispr Flow" button unreachable on Windows**

`wisprFlowPath` is resolved by matching `app.bundleId === WISPR_FLOW_BUNDLE_ID` — a macOS-only concept. On Windows, `getApplications()` returns apps identified by exe path, not a macOS-style bundle ID, so this lookup will always return `undefined` and the "Open Wispr Flow" action panel item will never render.

`search-transcripts.tsx` correctly builds a Windows exe-name → path map for source apps. The same approach (or using `appPathMap.get("wispr flow")` from a shared path map) is needed here to surface the Wispr Flow path on Windows.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/wispr-flow/src/search-transcripts.tsx
Line: 325

Comment:
**"Open Wispr Flow" lookup misses on Windows**

`appPathMap.get("com.electron.wispr-flow")` looks up by bundle ID. On Windows, `appPathMap` is keyed by lowercased exe names (e.g. `"wispr flow"`), so this key will never match and `wisprFlowPath` will always be `undefined` — hiding the "Open Wispr Flow" action on Windows.

A consistent key such as `"wispr flow"` (the exe stem) should be used on Windows, or a helper similar to `getWindowsAppPathMap` should also check for the Wispr Flow exe directly.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/wispr-flow/src/db.ts
Line: 89-106

Comment:
**Sync fallback blocks the event loop**

The PR description highlights "async writes," but the CLI fallback uses `execFileSync`, which is blocking and will freeze the Raycast UI thread for the duration of the SQLite write. Consider `execFileAsync` (via `promisify(execFile)`) or the async `execFile` callback form to keep the fallback non-blocking.

```typescript
const { execFile } = await import("node:child_process");
const execFileAsync = promisify(execFile);
try {
  await execFileAsync("sqlite3", [getDbPath()], { input: sql });
} catch (cliError) {
  // ...
}
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "Update wispr-flow extension" | Re-trigger Greptile}

[YONN2222]

I am implementing the fixes…