cue: an Electron overlay whose screen-share hiding the README calls best-effort

The first block in the file is a warning, and it is specific

Before any feature description, the readme opens with a block marked important and a request to read it first. Its content is a set of limits, and they are worth reading as a list of failure cases rather than as a disclaimer.

The application tries to stay out of screen recordings and shares, and the file states this is best-effort and not guaranteed. Three specific degradations are named: on macOS 15.4 and later Apple can let modern capture tools see the overlay anyway, on Windows 10 builds older than 2004 it degrades to a black box instead of true exclusion, and a phone camera always can see it.

Then the part that matters more than the technical detail. Using a hidden assistant during a proctored exam, a job interview, or a recorded meeting may break that platform's rules and, in some places, consent laws. The stated legitimate uses are your own notes, studying, accessibility, and practice, and the file closes by saying you are responsible for how you use it.

That framing is worth respecting on its own terms. The three named degradations describe an arms race the project is not claiming to win, and the legal paragraph is not a formality attached to a feature. Anyone evaluating this tool for an interview or a recorded call should treat the answer as already given in the documentation.

The platform table adds a fourth platform-specific note in the same spirit. Hidden from screen shares is marked as best-effort and weaker on macOS 15.4 and later on the Apple side, and as working through a specific Windows capture exclusion flag on the Microsoft side. So the feature matrix records the two platforms as genuinely different in kind rather than as one that works and one that does not.

Positioning is stated just as plainly. The header calls this a free, self-hosted alternative to a named commercial product, and the package description calls it a Cluely-style copilot for meetings and coding problems. The licence is GPL-3.0-or-later in the manifest, so the fork-and-modify path is open on the terms that require redistributed source.

The Releases link is a relative path out of the repository

The download instructions point at the releases page with a relative link written as two levels up:

../../releases

Rendered on GitHub, that resolves to a path outside the repository rather than to the releases list. The intent is unambiguous, since the surrounding text says to go to the releases page and choose a platform, and the three filenames that follow are real artifacts. But a reader following the link literally lands somewhere that is not a release index.

The same section names the three downloads precisely. On Windows the installer is a single executable for x64, which is unsigned, and the file warns that Windows SmartScreen may show an unknown publisher warning. On macOS there are two zips, one for Apple Silicon and one for Intel, and in both cases you unzip and drag the application bundle into Applications.

So the section is careful about filenames and careless about one link, which is the shape of documentation that has been edited as the project grew rather than written once. The unsigned Windows binary is called out plainly, and the unknown publisher warning is the thing a new user will hit first on that platform.

macOS asks for two permissions and Windows asks for one

The platform table makes the asymmetry plain. On macOS the permissions to grant are the microphone and screen recording. On Windows it is the microphone only, because screenshots and meeting audio need no permission at all and work immediately through Windows loopback capture.

That single difference cascades through the rest of the setup. On Windows the file says there is no permission dance, you grant the mic when the system asks and you are done. On macOS you go into system settings, turn on both entries, and macOS may ask you to quit and reopen the application, in which case the file says to let it.

Screen recording is what covers both halves of the macOS experience: it backs the screenshot features and it backs meeting audio capture. That coupling is why the meeting audio requirement carries a macOS version floor of its own, which is the next thing worth understanding.

There is also a first-run tutorial. The application walks through the same steps on first open, and the readme says you can reopen it from a help icon in the top-left of the panel. So the documented procedure and the in-app procedure are the same procedure, which is a small kindness for anyone debugging a permission problem later.

Meeting audio needs macOS 14.4, and gets there through two Chromium switches

cue separates its audio into two named channels. One is you, taken from the microphone. The other is them, taken from the meeting audio, meaning what the other person says. The two features that depend on the second channel are the what-should-I-say prompt and the recap.

The second channel is the fragile one. On Windows it works out of the box. On macOS it uses system audio loopback through ScreenCaptureKit, and the file explains that cue enables it through Chromium switches named MacLoopbackAudioForScreenShare and MacSckSystemAudioLoopbackOverride. The consequence on older macOS is spelled out: the them channel stays silent while your screen and the you channel keep working.

So the failure mode is partial, not total. On an unsupported macOS version you get a working overlay with a working microphone and a dead meeting channel, and the two features that depend on it return nothing rather than erroring. The platform table marks meeting audio as available on macOS 14.4 and later for the same reason.

The trigger table is where the channel split pays off. Each row pairs a shortcut with the inputs it consumes, so the routing is visible before you press anything. Smart assist takes a three-key chord on macOS and the control shift enter equivalent on Windows, and uses your screen plus recent conversation. The what-should-I-say prompt takes a two-key chord and uses meeting audio plus your microphone. Recap is a button rather than a shortcut and uses the whole conversation. Ask anything is typed text and a return key, using your screen plus conversation. The coding prompt is a single-key chord on each platform and uses your screen only.

The last row is a model switch rather than an action. A pill inside the box toggles between the default model and a smarter one that the file describes as slower, which is the only latency control the interface exposes. Nothing in the table lets you redirect the meeting channel, which is why the macOS version floor is a hardware and operating system constraint rather than a preference.

The build section lists its commands twice, and the second list has one extra

There are two build command lists in the same part of the file, introduced by similar sentences. The first is headed as building a standalone app and gives four commands:

npm run pack        # unpacked app in dist/ (either OS)
npm run pack:win    # unpacked Windows app -> dist/win-unpacked/cue.exe
npm run dist:mac    # macOS zip            -> dist/
npm run dist:win    # Windows installer    -> dist/cue-win-x64.exe

The second is headed as building a packaged app and repeats two of those commands verbatim before adding a third:

npm run dist:mac    # macOS build
npm run dist:win    # Windows build
npm run dist:linux  # Linux x64 AppImage

The difference between the lists is one line, and the heading difference is the only thing distinguishing an unpacked app from a packaged one. So the two blocks are not two workflows, they are the same workflow printed twice with one addition, and the Linux AppImage build exists without appearing in the platform support table above.

The manifest behind them goes further than either list. It defines a plain dist script that is identical to the mac one, separate per-architecture mac scripts, a Windows script, unpacked variants for both desktop platforms, and two Linux scripts for x64 and arm64 AppImages. So the package file supports eight packaging targets while the documentation shows five, which is harmless and slightly confusing in equal measure.

The test story is thinner than the build story by comparison. A single script runs the node test runner over a glob in a test directory, with no separate type check, no lint script and no coverage configuration in the manifest. A project with eight packaging targets and three provider integrations has one test entry point, so the automated safety net is thin relative to the surface.

Rebuilding on macOS resets the permission grants

The macOS note under the build commands describes a consequence that surprises people. The packaged application is ad-hoc signed unless a Developer ID certificate is configured, and macOS ties permission grants to the exact build, so rebuilding resets the microphone and screen recording permissions and you have to grant them again. The file gives the advice directly: for everyday use, build once and keep it. Windows is stated to have no equivalent problem.

The mechanism is the signature. An ad-hoc signature changes on every build, and the system's record of which binary the user granted microphone access to is keyed to that signed identity. Granting permission to a build and then replacing the binary leaves the grant pointing at something that no longer exists.

The same note reappears near the speech runtime setup, phrased as permission grants can reset after a rebuild so you may need to re-enable microphone and screen access after packaging a fresh build. Two placements for one warning, which is the file's way of making sure the point lands whether you read the build section top to bottom or skip to the runtime step.

For a developer this is a known cost and the advice is reasonable. For someone who rebuilds casually to pick up a change, it is a small recurring tax, and it is the main reason the daily-use path is the downloaded binary rather than a local build.

The speech runtime is vendored, not installed from npm

The dependency list contains no speech recognition package. The seven runtime dependencies are an Anthropic SDK, a Google generative AI SDK, the OpenAI SDK, an icon set, two document parsers and a websocket library. Transcription is handled by something else entirely.

That something is whisper.cpp, included in packaged builds as a pinned runtime. When you run from source you prepare the matching runtime yourself with a single command, and there is a second script whose job is to verify it.

The per-platform handling differs sharply, and the file is explicit about it. Windows x64 and Linux on x64 and arm64 use checksum-verified binaries taken from the pinned upstream release, so you get exactly the bytes the pin names. macOS on x64 and arm64 builds the server binary from that same pinned source tag instead, which means CMake and the Xcode command line tools are required.

So the one platform described as needing no Xcode anywhere else in the file does need the command line tools for packaging. The readme states earlier that running from source requires no Xcode and no Visual Studio build tools, and adds that the project deliberately avoids native modules, which is true of the JavaScript dependency graph and not of the packaging step.

The repository tree explains why the runtime is handled this way. There is a vendor directory at the root, so the speech binary has somewhere to live that is not the package registry, and a scripts directory holding the prepare and verify entry points that the manifest calls.

Two other things sit at the root and describe how the project is debugged. A file named for probing the Anthropic path and a second one named for probing the real path are both committed in the top level rather than tucked into scripts, and a verification file sits beside them. An install hook also runs a rename script automatically after every install, which is the kind of postinstall behaviour worth knowing about before you add this to a project rather than running it standalone.

The default backend is a shared account, and the pricing is disclosed on first run

The bring-your-own-key framing in the header does not describe the default. Packaged builds from the releases page run on a hosted service, and you need no account and no key to open the application. The header lists OpenAI, Anthropic, Google Gemini, Azure AI Foundry and OpenAI-compatible endpoints as the alternatives, which is where your own key comes in.

The first-run guide carries the disclosure, and the file repeats its terms rather than paraphrasing them. Every request costs 50 percent of the model's published list price. The average cost is stated as most people spending under two dollars a month. Prompts and screenshots go through that service's servers to a shared model account, and it never trains on them. Nothing is set up until you press continue, and a new computer starts with a balance of zero.

Four details there are worth more than the headline. The percentage is of list price rather than a flat rate, so the cost of a task moves with the model you select. The traffic goes to a shared account rather than an account of your own, which is a different privacy posture from a direct provider key even with the no-training promise. And the balance line lives in a settings screen next to a button for linking a computer and picking a plan, which is where the account relationship is actually established.

The documentation links to a first-run flow for the own-key path, and the section shown ends partway through describing what linking a computer to an account does.

Editorial conclusion

cue is a competent Electron application with a thoughtful trigger scheme and an unusually candid front page, and for its stated purposes your own notes, studying, accessibility work and practice, it does what it says. Three things to weigh before you install it. The concealment feature is the one most people will ask about, and the documentation does not promise it: it is described as best-effort, Apple can let modern capture tools see the overlay on recent macOS regardless, a phone camera always can, and older Windows builds degrade to a black box rather than true exclusion. Using it during a proctored exam, a job interview or a recorded meeting is where the project's own warning applies, and that is a rules and consent question rather than a technical one. Second, the packaged builds default to a hosted service rather than your own key, and the first-run disclosure states that requests cost half the model's published list price, that prompts and screenshots travel through that service's servers to a shared model account, and that it does not train on them; read that disclosure and switch to your own key if the routing matters. Third, this is a young project with two of its three recent tags released on the same day, and building on macOS requires CMake and the Xcode command line tools because the speech runtime is compiled from a pinned source tag rather than downloaded.

Frequently asked questions

Official sources

1. Blueturboguy07/cue on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases