Does CodeSignal Detect Screen Recording or Record Your Screen? (2026)

Direct Answer

CodeSignal records your screen only in proctored configurations, and only the single display, window, or tab you authorize through the browser's WebRTC capture dialog — it never performs an operating-system-level recording independent of that browser permission. The default unproctored practice assessment records nothing; Certified Assessments and proctored General Coding Assessments record the shared surface plus optional webcam and microphone feeds for the session. Because CodeSignal runs inside the browser sandbox, it cannot enumerate running processes, so it does not directly see a third-party recorder, a second monitor you did not share, a virtual desktop, or an overlay rendered outside the captured surface. What it does capture reliably is everything inside the shared region, every focus-loss and fullscreen-exit event, every paste, and the structural fingerprint of the submitted code. The phrase "CodeSignal records your screen" is true only within the boundary of the browser permission you granted.

Two Layers People Conflate: Recording vs Behavioral Logging

The first thing to separate is screen recording — an optional, permission-gated capture — from behavioral logging, which runs by default and needs no special grant. These are different mechanisms with different reach, and most candidate anxiety comes from merging them into one imagined surveillance system. Behavioral logging lives entirely inside the browser sandbox: the editor reads keystroke timing, paste events, and the browser's focus and visibility events, none of which require a screen-share permission. This layer runs on practice assessments and proctored assessments alike, and it is the layer that feeds the Suspicion Score described in the companion analysis of whether CodeSignal detects AI tools or cheating.

Screen recording is a separate, heavier mechanism that only activates when a recruiter enables proctoring on the assessment. At that point the candidate is prompted, before any code is written, to grant camera, microphone, and screen access through the browser. The screen capture is bounded by what the candidate selects in that dialog. So the honest answer to "does CodeSignal record my screen" splits cleanly: behavioral logging always runs; screen recording runs only under proctoring and only over the surface you authorized. Treating those as one thing is what produces the myth that the platform sees the entire machine.

What the Behavioral Layer Captures Without Any Recording

Even with screen recording switched off, CodeSignal's editor instruments the session through ordinary browser APIs, and this is the layer that catches the most common behaviors. The editor binds listeners to the browser's visibilitychange and blur events, so every time the assessment tab loses focus — a switch to another application, another tab, another window, or an exit from fullscreen — the platform records the moment and how long focus stayed away. It also logs each paste into the editor with a timestamp, the character length, and a hash of the pasted content, which lets a recruiter later see whether a pasted block matches the problem statement or arrived from outside.

These signals require no screen permission because they are emitted by the browser itself to any page that listens. That is why a candidate who briefly checks a chat window during a take-home assessment generates a visible focus-loss event even though nothing was recording the display. The pattern that lights up the Suspicion Score most strongly is a focus loss followed by a long pause followed by a large paste — copy the prompt, leave to solve it elsewhere, return, and paste the result. The events sit adjacent in the timeline, which is why this combination is so reliably flagged. The mechanics of focus and paste detection across platforms are covered in can interviewers see paste events.

What Each CodeSignal Product Actually Records

Recording scope is not uniform across CodeSignal's products — it is set by the proctoring configuration the recruiter or credential program chooses. The matrix below maps each signal against the unproctored GCA, the proctored Certified or secure GCA configuration, and the live Interview product, and the pattern is that recording deepens as proctoring tightens while the browser boundary stays fixed throughout.

The bottom four rows are constant across every product, because they describe the architectural boundary of a browser-based proctor rather than a configuration toggle. No CodeSignal product performs an OS-level recording, sees an unshared monitor, or detects an overlay that stays out of the captured surface. The top rows scale with the proctoring tier. A candidate told they will take a "CodeSignal assessment" should ask which configuration applies, because that single fact determines whether any recording happens at all — the same advice that governs preparation for proctored coding tests in general.

The Capture Boundary: getDisplayMedia and Why It Stops at the Browser

The recording scope is not a CodeSignal policy choice; it is dictated by the browser API the platform relies on. When proctoring asks for a screen, CodeSignal calls the standard WebRTC getDisplayMedia API, and the browser — not CodeSignal — presents the source picker and enforces the boundary. A simplified view of what happens when the recording request fires:

async function startProctoredCapture(session):
    # CodeSignal can only REQUEST capture; the browser decides scope.
    stream = await navigator.mediaDevices.getDisplayMedia({
        video: { displaySurface: "monitor" },   # or "window" / "browser"
        audio: false
    })

    chosen = stream.getVideoTracks()[0].getSettings()
    # chosen.displaySurface == exactly ONE surface the user clicked:
    #   one monitor, OR one window, OR one tab.
    # Everything else is OUTSIDE this MediaStream:
    #   - other physical monitors (separate, unselected sources)
    #   - other virtual desktops
    #   - overlay windows that opt out of capture
    #   - the OS compositor layers below the chosen surface

    session.recorder.attach(stream)        # records ONLY `chosen`
    session.bindFocusEvents(window)        # visibilitychange + blur
    session.bindPasteHash(editor)          # paste length + content hash
    # No call exists here to read the process list, scan drivers,
    # or capture a surface the user did not select — the browser
    # sandbox provides no such API to a web page.

The page never receives a handle to anything except the single surface the user selected, and the browser sandbox exposes no API for a web page to read the process list, enumerate drivers, or grab a second display. This is the same constraint that bounds every browser-based assessment platform, and it is why the second-monitor and overlay rows in the matrix above are constant. Codility addresses part of this gap with a downloadable desktop app that scans processes; the contrast is laid out in whether Codility detects screen recording or second screens.

What CodeSignal Structurally Cannot Capture

There is a hard line around CodeSignal's reach, and it follows directly from running inside the browser rather than as a system-level agent. Because the page only holds the one getDisplayMedia surface, a second physical monitor that the candidate did not select is simply not in the recording — it is a different, unselected capture source. A virtual desktop the candidate switches to is likewise outside the stream. An overlay window that opts out of the display compositor's capture path never enters the buffer even if the candidate shared the entire screen, because the operating system never composites it into the captured surface in the first place.

Third-party recording software falls outside the boundary for the same reason: CodeSignal cannot read the process list from a sandboxed page, so it has no list of "is OBS running" to consult. The only way such a tool shows up is if its own window happens to sit inside the region the candidate shared, in which case it is recorded as ordinary pixels — not because CodeSignal detected the software, but because the candidate shared a region containing it. The architectural reasoning here mirrors the broader treatment of how invisible assistants stay out of capture in how AI interview assistants work.

Does CodeSignal scan my computer for cheating software before the test? No — actually, unlike platforms that ship a downloadable integrity app, CodeSignal's proctoring runs in the browser and performs no process scan or driver enumeration. It captures what the browser permits and infers the rest from behavior.

The Identity-Verification Step and What It Actually Establishes

Before any proctored assessment begins, CodeSignal runs an identity gate, and understanding it clarifies what the recording is for. The candidate is prompted to share camera, microphone, and screen, then to hold a government-issued photo ID up to the camera so the proctoring verification team can match the face to the document. This step converts a username into a verified face, which is the foundation of the platform's defense against proxy test-takers — a different person sitting the assessment on the candidate's behalf. If the face on camera during the session does not match the ID presented at the start, the proctoring team has a concrete discrepancy to act on.

The identity step is also why the recording exists at all in proctored mode: the captured surfaces and the webcam feed are retained so a human verification team can review them after submission, and CodeSignal's published policy stores and deletes that data within roughly fifteen days. The recording is not fed into a real-time vision model that auto-rejects candidates; it is an evidence trail attached to the report for human review, with the Suspicion Score and timeline markers directing where reviewers look. This human-in-the-loop design is the same posture described for the Suspicion Score and AI-detection stack, and it is the reason a flag is a prompt for review rather than an automatic verdict.

Webcam Proctoring Is a Separate Layer

The webcam feed is a distinct optional mechanism from screen recording, and candidates frequently merge the two into a single fear. When a proctored assessment enables webcam proctoring, CodeSignal captures either periodic identity snapshots or a continuous video feed, and it pairs an ID-verification step where the candidate holds a government-issued photo ID to the camera so the proctoring team can match the face to the identity. This is the layer that approximates "is the candidate looking away from the screen" — off-screen gaze is a webcam signal, not a screen-recording signal.

Crucially, the webcam layer and the screen layer can be enabled independently. An assessment can record the screen without the webcam, capture the webcam without recording the screen, or do both. The webcam catches what the screen recording cannot — a phone propped beside the laptop, a second monitor the candidate keeps glancing at, a person off to the side — but only as visual cues in the camera frame, never as data about the contents of those devices. The webcam cannot read a phone screen; it can only show that the candidate looked toward one. The full breakdown of how camera-based monitoring works across vendors is in webcam proctoring software.

Live vs Async: The Detection Surface Shifts

The recording scope also depends on whether the assessment is an asynchronous test or a live interview, because the two formats put different observers behind the same instrumentation. The asynchronous GCA and Certified Assessment are reviewed after the fact: the recording, the focus timeline, the paste log, and the Suspicion Score are examined by a recruiter or proctoring team once the candidate submits. There is no human watching in real time, so the entire detection burden falls on the recorded artifacts and the composite score.

CodeSignal Interview, the live product, replaces the recorded-and-reviewed model with a human interviewer present on a shared editor in real time. Here the focus-loss and paste events are still logged, but a live interviewer is also forming a direct impression of the candidate's reasoning, which is a judgment no recording reproduces. The async format is more instrumented and less personal; the live format is less instrumented and more observed. Candidates who assume both formats behave identically are usually wrong about which signals matter, a distinction that also separates the AI-detection behavior covered in does CodeSignal detect AI from live interviewing entirely.

False Positives: When the Recording Scope Misleads a Reviewer

The recording scope produces its own characteristic false positives, and knowing them matters because a genuine candidate can be flagged by the same instrumentation that catches a cheating one. The most common is the focus-loss artifact: an operating-system notification banner, a screen-reader or accessibility tool that steals focus, or an errant trackpad gesture can fire a blur event that lands in the timeline as a tab switch even though the candidate never left the assessment. Pasting a solution drafted in an external editor for formatting reasons produces a large paste event indistinguishable, at the event level, from pasting an externally sourced answer. A candidate who reproduces a canonical solution they genuinely learned can trip the similarity comparison without any external help.

The screen recording itself can mislead in the other direction. Because the recording captures only the shared surface, a reviewer watching it sees a clean session even when a separate device sat just outside the camera frame — the recording cannot prove innocence any more than it can prove guilt about what happened off-surface. CodeSignal's documentation is explicit that a high Suspicion Score is a flag for human review rather than proof, and a well-run hiring team treats it that way. The pattern of capable candidates being disadvantaged by integrity tooling is the through-line of why qualified candidates fail technical interviews, and it is the strongest argument for pairing any automated flag with a structured human follow-up.

Does a clean screen recording clear me of suspicion automatically? No — actually the recording only covers the surface you shared, so a reviewer still weighs the focus log, the paste hashes, the webcam if enabled, and the AI-code classifier. A clean recording is one input among several, not an acquittal.

What Detection Means in Practice for a 2026 Candidate

The practical surface for a candidate facing a proctored CodeSignal assessment in 2026 has three tiers, and the recording is only one of them. The first tier is the always-on behavioral layer — focus loss, fullscreen exits, paste hashes, typing rhythm — which runs whether or not anything is recording and is the easiest to trigger by accident. The second tier is the optional recording layer — the authorized screen capture plus the webcam and microphone — which exists primarily as an evidence trail for human review rather than as a real-time blocker. The third tier is the post-submission analysis — the similarity comparison and the AI-code classifier on the final code — which is deterministic in a way the behavioral layer is not.

A high composite Suspicion Score does not auto-reject; it routes the submission into a manual-review queue where a human examines the recording, the timeline, and the code together. The cost of landing in that queue is real at the top-tier employers that use CodeSignal for first-round screens, where the recruiter has wide discretion over the outcome — the screening bar at companies whose pipelines are profiled in the Palantir technical interview process and the Airbnb technical interview process leaves little room for a contested flag to be resolved in the candidate's favor by default. The durable answer is not to outguess the recording boundary but to prepare so performance does not hinge on any single external factor — the same conclusion reached across the platform-detection coverage and the reason confirming the assessment configuration up front, as in how to pass a proctored coding test, is the most useful first move a candidate can make.

CodeSignal vs Codility vs HackerRank: Where the Recording Boundaries Diverge

The recording question is best understood by comparing CodeSignal against the two platforms candidates most often confuse it with, because all three share the browser boundary but differ in what they bolt on top of it. CodeSignal's proctoring is browser-only: it records the WebRTC surface, runs the behavioral layer, and analyzes the submission, but it never installs a system agent and therefore never scans the process list. Codility offers an optional downloadable Device Integrity App that does scan running processes and enumerate connected displays at session start, which gives it a narrow window into the machine that CodeSignal's browser-only stack lacks — the full mechanics of that app are laid out in does Codility detect screen recording or second screens. HackerRank rolls its signals into a single integrity score and leans hard on in-session video proctoring.

The consequence for the recording question is concrete. On CodeSignal, a second monitor is invisible to the recording unless shared, and an overlay outside the captured surface is invisible regardless — there is no process scan to catch a recorder by name. On Codility with Device Integrity enabled, the same overlay or recorder can be caught at session start if its binary signature sits on the denylist, even though Codility's recording boundary is otherwise identical. The lesson is that "browser-based proctoring" is not one uniform thing: the recording surface is the same across all three, but the supplementary detection — process scans, integrity scores, video models — is where they diverge, and a candidate should ask which supplements are active rather than assuming the recording alone defines the platform's reach.

What Candidates Get Wrong

Most CodeSignal recording myths come from assuming the platform reaches further into the machine than a browser-based tool actually can. Each of the following collapses once the capture boundary is clear.

• Believing CodeSignal records the whole operating system. It records the single WebRTC surface the candidate authorized plus optional camera and microphone. There is no kernel-level capture and no view beneath the shared surface.
• Assuming the platform scans for OBS or other recorders. A sandboxed web page cannot read the process list. CodeSignal does not enumerate running software; a recorder is only ever visible if its window is inside the shared region.
• Thinking screen recording and webcam recording are one feature. They are independent toggles. One can run without the other, and they catch different things — on-display activity versus the physical scene in front of the camera.
• Treating an unshared second monitor as captured. Each display is a separate capture source. A monitor the candidate did not select is not in the recording, though the webcam may catch glances toward it.
• Ignoring the behavioral layer because recording is off. Focus events, fullscreen exits, and paste hashes run with no screen permission at all and feed the Suspicion Score on every assessment, proctored or not.
• Not asking whether proctoring is even enabled. Practice and unproctored assessments record nothing. The recruiter's configuration decides the entire recording surface, so confirming it is the single most useful question a candidate can ask.

Frequently Asked Questions

Does CodeSignal record your entire screen or just the assessment tab? It records whatever single surface you select in the browser's capture dialog. If you choose the entire display, that one display is recorded for the session; if a tab-only option is offered and you choose it, only that tab is captured. CodeSignal cannot record more than the one surface the browser hands it, and it never captures a monitor you did not select.

Can CodeSignal detect screen recording software running in the background? Not directly. CodeSignal runs inside the browser sandbox and has no API to read the operating system's process list, so it cannot see OBS, QuickTime, or a system recorder as software. The only way such a tool appears is if its window sits inside the screen region you shared, in which case it is recorded as ordinary pixels rather than detected as a program.

Does CodeSignal record my screen if the assessment is unproctored? No. Unproctored and practice assessments do not request screen, camera, or microphone access and record none of them. They still log behavioral signals — focus loss, paste events, typing rhythm — through the browser, but there is no screen or webcam recording unless a recruiter has explicitly enabled proctoring on that assessment.

Will CodeSignal catch me if I use a second laptop or phone? Not through screen recording. A separate device runs on its own hardware that CodeSignal has no connection to, so its contents are invisible to the platform. The webcam layer, if enabled, may capture you looking toward or reaching for another device, but it records the visual cue, not the device's screen.

Does exiting fullscreen during a CodeSignal assessment get flagged? Yes. Fullscreen exit fires a focus-related event that the editor logs with a timestamp, and it contributes to the Suspicion Score and appears in the recruiter's timeline. Repeated fullscreen exits, especially clustered with paste events, raise the composite suspicion level even when nothing on the shared surface looks unusual.