The Control Journal
TechnicalJanuary 12, 202620 min read

How Control Works: Technical Deep Dive

A comprehensive technical breakdown of Control's architecture, stealth technology, and why most competitors claiming macOS invisibility are lying.

CControl Editorial Team · Updated Mar 29, 2026

Control is built from the ground up to be completely invisible during coding interviews. This post explains the technical architecture that makes true stealth possible - and why most competitors claiming macOS invisibility are lying to you.

The macOS 15+ Invisibility Problem

Most interview tools claiming "invisible on macOS" are lying. Here's why.

The setContentProtection Failure

The standard method for hiding windows from screen capture on macOS is setContentProtection(true) in Electron. This worked fine until macOS 15 (Sequoia), when Apple broke it completely.

// This used to work, but is now BROKEN on macOS 15+
overlayWindow.setContentProtection(true);

Why it broke: Apple replaced their legacy CoreGraphics capture APIs with a new framework called ScreenCaptureKit. This new framework intentionally ignores the old window protection flags.

Why ScreenCaptureKit Bypasses Protection

The technical reason is architectural:

  1. Old System: CoreGraphics captured individual window buffers and respected NSWindowSharingType flags
  2. New System: ScreenCaptureKit captures at the compositor level - the final rendered framebuffer - ignoring all legacy protection flags

Apple designed this intentionally. They want the user and capturing application to control what's captured, not the application being captured.

What This Means for Competitors

Any tool using standard Electron setContentProtection(true) is completely visible on macOS 15+. This includes most interview assistants that claim "invisible on Mac."

If a competitor launched before 2024 and hasn't specifically addressed this issue, their macOS invisibility claims are false.

How Control Actually Achieves macOS Invisibility

Control uses an undocumented private API that Chromium developers discovered. This is the only known method that actually works on macOS 15+.

The CGSSetWindowCaptureExcludeShape Workaround

// The actual fix using undocumented CGS APIs
CGSConnectionID connection_id = CGSMainConnectionID();
CGSWindowID window_id = ns_window().windowNumber;
CGRect frame = ns_window().frame;
frame.origin = CGPointZero;

CGRegionRef region = CGRegionCreateWithRect(frame);
CGSSetWindowCaptureExcludeShape(connection_id, window_id, region);

This creates an "exclude shape" that covers the entire window, forcing the system compositor to "punch a hole" in the screen capture where our window would appear.

Why Other Tools Don't Use This

Mac App Store Compliance: Apple prohibits undocumented APIs. Any app using this fix gets rejected from the App Store.

Control is distributed directly, not through the App Store, so we can use the fix that actually works.

Comparison of Protection Methods

MethodmacOS 15+ StatusReliabilityApp Store Safe
NSWindowSharingTypeBrokenNoneYes
setContentProtectionBrokenNoneYes
CGSSetWindowCaptureExcludeShapeWorkingHighNo

Control uses CGSSetWindowCaptureExcludeShape - the only method that actually works.

Architecture Overview

Control consists of three main components:

  1. Desktop Application - Electron-based overlay with OS-level stealth
  2. Web Dashboard - Next.js app for mobile remote control
  3. AI Backend - Bifrost proxy routing to OpenAI/Anthropic
┌─────────────────────────────────────────────────────┐
│                    Desktop Overlay                   │
│  ┌─────────────┐    ┌────────────────────────────┐  │
│  │Screen Capture│    │ Invisible Overlay Window   │  │
│  └──────┬──────┘    └──────────────┬─────────────┘  │
│         │                          │                │
│         └──────────┬───────────────┘                │
│                    ↓                                │
│         ┌─────────────────────┐                     │
│         │    Bifrost Proxy    │                     │
│         └──────────┬──────────┘                     │
│                    ↓                                │
│         ┌─────────────────────┐                     │
│         │   OpenAI/Anthropic  │                     │
│         └─────────────────────┘                     │
└─────────────────────────────────────────────────────┘

The Stealth Layer

Platform-Specific Implementation

Control uses different stealth mechanisms for each operating system because each has different screen capture architectures.

Windows Implementation

On Windows, we use the standard WS_EX_TOOLWINDOW and display affinity flags:

const overlayWindow = new BrowserWindow({
  transparent: true,
  frame: false,
  skipTaskbar: true,
  alwaysOnTop: true,
  // Windows respects these flags
  type: 'toolbar'
});

// Windows-specific: Set display affinity to exclude from capture
overlayWindow.setContentProtection(true); // Actually works on Windows

Windows still respects the legacy protection APIs, so standard Electron methods work fine.

macOS Implementation (The Hard Part)

As explained above, macOS 15+ broke standard protection. Control uses a native module that calls the undocumented CGS APIs:

// Our native module for macOS 15+ compatibility
import { setWindowCaptureExclusion } from './native/macos-stealth';

const overlayWindow = new BrowserWindow({
  transparent: true,
  frame: false,
  skipTaskbar: true,
  alwaysOnTop: true,
  type: 'panel'
});

// The standard method (kept for older macOS versions)
overlayWindow.setContentProtection(true);

// The actual fix for macOS 15+
if (process.platform === 'darwin') {
  setWindowCaptureExclusion(overlayWindow.getNativeWindowHandle(), true);
}

The native module implementation:

// native/macos-stealth.mm
#import <Cocoa/Cocoa.h>

extern "C" {
  CGSConnectionID CGSMainConnectionID(void);
  CGError CGSSetWindowCaptureExcludeShape(CGSConnectionID cid, 
                                           CGSWindowID wid, 
                                           CGRegionRef region);
}

void SetWindowCaptureExclusion(NSWindow* window, bool exclude) {
  CGSConnectionID connection = CGSMainConnectionID();
  CGSWindowID windowId = [window windowNumber];
  
  if (exclude) {
    CGRect frame = [window frame];
    frame.origin = CGPointZero;
    CGRegionRef region = CGRegionCreateWithRect(frame);
    CGSSetWindowCaptureExcludeShape(connection, windowId, region);
    CGRegionRelease(region);
  } else {
    CGSSetWindowCaptureExcludeShape(connection, windowId, NULL);
  }
}

Why Browser-Based Solutions Always Fail

Browser-based interview tools try to hide overlays using CSS tricks:

// This NEVER works for screen capture
overlay.style.zIndex = '999999';
overlay.style.opacity = '0.99';

No matter what CSS you apply, the element is still in the browser's render tree. When any screen capture API requests the browser's content, the overlay is included.

The only way to be truly invisible is to exist outside the browser entirely - which requires a native desktop application like Control.

Hotkey System

OS-Level Keyboard Hooks

Control intercepts keyboard events at the OS level, before they reach any application:

import { globalShortcut } from 'electron';

// Register global shortcuts
globalShortcut.register('CommandOrControl+Shift+S', () => {
  captureAndAnalyze();
});

globalShortcut.register('CommandOrControl+Shift+H', () => {
  toggleOverlayVisibility();
});

Why Browser-Based Hotkeys Fail

Browser-based tools register event listeners like this:

document.addEventListener('keydown', handler);

The problem is that proctoring software can also register listeners and see every keystroke. They can detect unusual key combinations and flag suspicious behavior.

Control's hotkeys never generate browser events. The OS intercepts them before they reach any application, making them completely invisible to JavaScript running in the browser.

Focus Management

The Click-Through Window

One of the most common ways interview tools get detected is through focus events. When you click on an overlay, the browser loses focus and fires a blur event. Proctoring software monitors these events.

Control solves this with a click-through window:

// Enable click-through by default
overlayWindow.setIgnoreMouseEvents(true);

// Temporarily disable for interaction
ipcMain.on('enable-interaction', () => {
  overlayWindow.setIgnoreMouseEvents(false);
});

ipcMain.on('disable-interaction', () => {
  overlayWindow.setIgnoreMouseEvents(true);
});

When click-through is enabled, mouse events pass through the overlay window to whatever is behind it. The browser never loses focus, and no blur events are fired.

Screen Capture Pipeline

How Screenshots Work

When you trigger a capture, Control:

  1. Takes a screenshot of the specified region
  2. Sends the image to the AI backend
  3. Receives the analysis/solution
  4. Displays it in the overlay
async function captureAndAnalyze() {
  // Capture screen region
  const sources = await desktopCapturer.getSources({
    types: ['screen'],
    thumbnailSize: { width: 1920, height: 1080 }
  });
  
  const screenshot = sources[0].thumbnail;
  
  // Send to AI
  const response = await fetch('/api/analyze', {
    method: 'POST',
    body: JSON.stringify({
      image: screenshot.toDataURL(),
      context: getCurrentContext()
    })
  });
  
  const solution = await response.json();
  
  // Display in overlay
  overlayWindow.webContents.send('display-solution', solution);
}

OCR and Problem Detection

Control uses vision models to understand the coding problem on screen:

  1. Screenshot is sent to GPT-4 Vision or Claude
  2. Model extracts the problem statement, constraints, and examples
  3. Model generates a solution with explanation
  4. Response is formatted and displayed

Mobile Remote Control

WebSocket Architecture

Control includes a mobile dashboard that lets you control the desktop app from your phone:

// Desktop: WebSocket server
const wss = new WebSocketServer({ port: 8080 });

wss.on('co...

Continue exploring