---
title: "PerimeterX press and hold: 2 presses, 1 call"
description: "How the HUMAN (PerimeterX) press and hold works, why one long press fails, and how an AI agent passed it on Microsoft's sign-up in 3 runs on 4 August 2026."
canonical: "https://scalebrowser.net/blog/perimeterx-press-and-hold"
last_modified: "2026-10-11"
published: "2026-10-11"
author: "davide"
category: "challenges"
---
> ## Documentation Index
> Fetch the complete documentation index at: https://scalebrowser.net/llms.txt
> Use this file to discover all available pages before exploring further.
# PerimeterX press and hold: 2 presses, 1 call
> How the HUMAN (PerimeterX) press and hold works, why one long press fails, and how an AI agent passed it on Microsoft's sign-up in 3 runs on 4 August 2026.
The press and hold button looks like the friendliest challenge on the web: no pictures, no words, just a button that fills up while you hold it. It is also the one where scripts fail most quietly. Our agent's first attempts pressed exactly the right element for exactly long enough, every event arrived, and nothing happened. The reason was written on the page all along.
## What is the PerimeterX press and hold?
The PerimeterX press and hold is HUMAN Security's challenge in which a visitor presses a button and holds it until the check completes. PerimeterX built it before it merged with HUMAN Security, formerly White Ops; [the merger was reported on 28 July 2022](https://www.helpnetsecurity.com/2022/07/28/human-security-perimeterx/), and the combined company kept the HUMAN name with "more than 450 employees" and "500+ customers". Developers still call the challenge PerimeterX, and the button still carries that name in its markup.
HUMAN's [documentation](https://docs.humansecurity.com/applications/human-challenge) calls it "a simple, no-hassle 'press and hold' challenge". A person who cannot hold a button has a second way through when the site enables the vendor's ["Enhanced Accessibility Mode"](https://docs.humansecurity.com/applications/customize-challenge-page): the page offers to "press tab for an accessible version", which asks for an email address and a temporary verification code instead of the hold. HUMAN describes that mode as WCAG 2.2 certified, with accommodations that include blindness, deafness, limited movement and photosensitivity.
| Property | HUMAN press and hold |
| --- | --- |
| Vendor | HUMAN Security, formerly PerimeterX |
| What the visitor does | presses a button and keeps it pressed until the bar is full |
| Accessible alternative | an emailed verification code, if the site enables it |
| Where it has been reported | Microsoft account sign-up (our runs, 4 August 2026), Wayfair (a developer's report, June 2024) |
### When does the press and hold appear?
The press and hold appears when HUMAN's sensor rates a visitor as a likely bot, at two moments the vendor [describes in its challenge settings](https://docs.humansecurity.com/applications/set-challenge-configurations). The first is before a page, when a suspected bot gets the challenge instead of the content. The second is in the middle of a page: with "Auto ABR" on, the challenge appears "whenever Sightline detects suspicious API requests sent outside of the original page request", laid over the page the visitor is already on. The site owner decides which of these is switched on; we met the challenge on Microsoft's account sign-up at signup.live.com.
## Why does one long press fail?
One long press fails because the check is still asleep when it starts. The widget says so in plain words: press once, wait for the confirmation, then press again. A single long press lands on the right element and is ignored anyway; after it, the widget rebuilds itself, and every further report goes into a different execution context than the one being scored. What the vendor then evaluates is an empty hold.
How long the hold itself must last is not published. The one place the vendor states a range is its [integration testing guide](https://docs.humansecurity.com/applications/human-challenge-integration-testing-process) for site owners: with a bypass token, a test can fix the solve time "between 1000 and 10000" milliseconds, that is 1 to 10 seconds. Outside that test mode the duration is the vendor's decision, and the same guide notes that a failed solve is answered with "another challenge", not with an error.
That is why the failure is so hard to see from the driver's side. The click arrives, the button fills, no error comes back, and the page simply stays where it was. Developers on the free path describe the same wall: in a [puppeteer-extra issue](https://github.com/berstend/puppeteer-extra/issues/893) opened on 4 June 2024 and still open in September 2026, a user building a scraper wrote "I have tried simulating user actions to bypass it, but it seems that there is some underlying mechanism to detect bots." Before blaming detection, read what the widget asks for.
We also ruled out the other explanation before touching our own code. On the same day, an externally calibrated reference solver passed the challenge twice in the same browser profile. That separated "our chain is broken" from "our browser is recognised", and it was the first one.
## How does one call carry both presses?
One call carries both presses because the wake press, the pause and the long hold form one timeline inside the daemon, and the agent only asks for the gesture. The agent calls `press_and_hold` once on the button; the daemon plays the whole sequence through the same input layer that moves every other pointer. It is one of the [18 measured challenge types](/blog/captcha-solving) our agent has solved through its own tools.
| Runs | Tool calls per run | Outcome | Note |
| --- | --- | --- | --- |
| 2 | 1 | challenge passed, sign-up continued | no person near the machine |
| 1 | 2 | challenge passed on the second call | a real mouse pointer sat over the window |
The third run did not fail on the gesture. Someone's hand was on the mouse over the visible browser window, genuine input mixed with the dispatched input, and the widget refused the first attempt. The rule we took from it is simple: measure headless, or keep your hands off the machine while a challenge runs.
### How do slider challenges compare?
Slider challenges fail for a different reason: the agent has to know a distance, not a sequence. Where the press and hold hides its difficulty in timing, a GeeTest slider hides it in pixels, and the slider captcha gap of 112 pixels was measured from the image and passed in one drag. Both run through the same input layer, so neither reaches the page as a single synthetic event.
## What should you check before a press and hold run?
Check four things before you count a run. Read the widget's own text first, because this challenge states its two-press rule on screen. Keep people and their pointers away from a visible window while the agent works. Count a run as passed only when the page moves on to the next step of the sign-up; a filled button without that step is not a pass. And space your runs: HUMAN's own testing guide tells site owners to "wait 5-10 minutes for the challenge solve to expire", so a second run right after a solve may not be challenged at all and proves nothing about the gesture. The [verification page of the documentation](/docs/agents/verification) keeps the current status of this and every other challenge type.