
How Undetectable Interview Assistants Actually Work
Screen-share invisibility is not a trick or a hack. It is two operating-system APIs and one architectural decision. Here is exactly what happens to the pixels, and what it cannot do.
How Undetectable Interview Assistants Actually Work
Every tool in this category makes the same claim: the interviewer cannot see it. Almost none of them explain why.
That gap is worth closing, because the explanation is short, verifiable, and it also tells you precisely where the guarantee stops. If you are going to rely on this in a real interview, you should understand the mechanism rather than trust the marketing.
What "sharing your screen" actually is
When you share your screen, the meeting app does not read your monitor. It asks the operating system for a stream of composited frames.
The compositor is the part of the OS that takes every window β your editor, your browser, your notifications β and paints them into the single image you see. Screen sharing is a second consumer of that same pipeline. Zoom, Meet, Teams, OBS, and the screenshot key are all downstream of it.
That is the whole leverage point. If a window is excluded before the frame is composited for capture, every consumer of that frame is affected at once. There is no per-app cat and mouse, because none of the apps are involved in the decision.
The two APIs
Operating systems expose this deliberately. It exists for password managers, banking apps, and DRM β anything that should not end up in a support-call recording.
macOS. A window sets sharingType = .none on its NSWindow. From that point, the window is omitted from screen-sharing and screen-capture output, including ScreenCaptureKit consumers and the built-in screenshot tools. In an Electron app the same thing is reachable as win.setContentProtection(true), which maps down to the native flag.
Windows. A window calls SetWindowDisplayAffinity(hwnd, WDA_EXCLUDEFROMCAPTURE). On Windows 10 version 2004 and later, the window is excluded from capture entirely. On older builds the earlier WDA_MONITOR affinity rendered it as a black rectangle instead β visibly a hole, which is why the newer flag matters.
Both are one-line requests to the compositor. There is nothing clever in the calling code, and nothing to keep patched as meeting apps update.
Why there is nothing to detect
This is the part people get wrong, in both directions.
The meeting app does not receive a frame with a masked region, a transparent layer, or a suspicious gap. It receives a frame that was composited without that window at all. From its point of view, the window does not exist. There is no artefact, no timing signal, no alpha channel oddity β nothing to notice, because nothing was subtracted after the fact.
The same applies to a recorded meeting: the recording is made from the same captured frames, so the assistant is absent from the recording too. And to screenshots, for the same reason.
What this does not mean is that the process is invisible. Anything running on the machine can be enumerated by anything else running on the machine with sufficient privileges. Capture exclusion is about pixels, not about processes.
The architectural half
The API is only half the story. The other half decides whether the API can help you at all.
A browser extension cannot do this. An extension runs inside a browser tab, and the browser window is the thing being shared. Excluding it would mean excluding your entire browser. The best an extension can do is hide itself from a screenshot of the page β which is not the same problem, and not the one you have during a screen share.
A separate desktop overlay can. The assistant draws its own top-level window: frameless, transparent, always on top, and often click-through so mouse events pass to whatever is underneath. That window is the one flagged for capture exclusion. Nothing is injected into the meeting client, no extension is installed, and the meeting itself is untouched.
That is why the tools that hold up under a real screen share are all native desktop apps, and why the ones that live in your browser tend to hedge their language.
A few implementation details follow from the overlay approach:
- The window usually stays out of the Dock, the app switcher, and the taskbar, so a stray Cmd-Tab does not surface it.
- It has to survive display changes β plugging in a monitor, changing resolution, a screen lock β without losing the exclusion flag.
- Any secondary window it opens (chat, settings, a report view) needs the same flag, or the tool leaks through the one window nobody remembered.
That last one is the most common real-world bug in this category. Invisibility is a property of every window an app owns, not of the app.
How to verify it yourself in two minutes
Never take this on trust. It is trivially testable:
- Open the assistant and make sure invisible mode is on.
- Start a meeting with yourself in Zoom, Google Meet, or Teams.
- Share your entire screen β not a single window, which would prove nothing.
- Look at the self-preview. The assistant should be absent.
- Press your screenshot key. It should be absent from the image too.
If it shows up in either, the exclusion is not applied, and no amount of marketing changes that. Do this before an interview, not during one.
Where the guarantee ends
An honest version of this article has to include this section.
Capture exclusion controls what a capture API receives. It does not control physics or the rest of your environment:
- A second camera or a phone pointed at your screen sees your monitor directly. The compositor is not involved.
- A person in the room is not a capture API.
- Your eyes still move. If the overlay sits far from where you are supposed to be looking, that is the tell, not the pixels.
- Locked-down proctoring environments that take over the machine, and company-managed devices running monitoring agents, are a different threat model entirely. Do not assume anything holds there.
- Policy is not technology. Invisibility is a privacy feature. It is not permission to break the rules of a process you agreed to.
Anyone who tells you a capture-exclusion flag makes you undetectable is describing something the API does not claim.
The short version
Two OS calls and one architectural decision. sharingType = .none on macOS, WDA_EXCLUDEFROMCAPTURE on Windows, applied to a separate always-on-top overlay window rather than something inside the browser you are sharing.
Simple enough that it works reliably. Specific enough that you know exactly what it covers.
More on the feature and what ships in each plan: /undetectability. GeekBye includes it on every plan, free ones too.
Related: how to stay invisible during screen sharing Β· GeekBye vs Cluely Β· getting started