agent's LinkedIn login hit a checkpoint challenge - it couldn't solve the 'verify it's you' screen and the whole...
Tells an SDR agent what to do when LinkedIn shows a verify-it's-you checkpoint: stop, pause the sequence, and alert a human. Never attempt to solve or bypass the challenge. Use when an automated login hits a checkpoint and the agent has no legitimate path through. Not for wrong-password loops, session refresh logic, or API access, which have their own paths.
TL;DR
A checkpoint is the platform telling you to stop, so stop. When the verify-it's-you screen appears, the agent halts the login, pauses the affected sequence, and alerts a human operator. It does not try to solve the challenge, guess at it, or find another way in, because repeated attempts look like the abuse the checkpoint exists to catch. The skill here is stopping cleanly and staying stopped until a human clears it.
agent's LinkedIn login hit a checkpoint challenge - it couldn't solve the 'verify it's you' screen and the whole sequence stalledSteps
Detect the checkpoint explicitly: match on the challenge screen's markers in your login flow and treat it as a distinct outcome, not as a generic login failure. Expected: a checkpoint in staging is classified as checkpointdetected, not as badpassword or timeout.
On detection, halt the login flow immediately. No retries, no alternate entry points, no waiting and trying again in an hour. One detection means the session work stops. Expected: the run log shows exactly one checkpoint detection followed by a clean halt, with zero further login attempts.
Pause the dependent sequence or prospecting job and record why, so nothing else keeps hammering the account while the checkpoint is unresolved. Expected: the sequence shows pausedforcheckpoint and no further actions are attempted against the account.
Alert a human operator with the account, the time, and what was running. The operator resolves the checkpoint manually in a real browser and then re-enables the job. Expected: the operator gets the alert within minutes and the job stays paused until they explicitly resume it.
After a checkpoint, add a cool-down before resuming automation, and review what triggered it: new IP, new device fingerprint, unusual volume. Fix the trigger before restarting. Expected: the post-checkpoint review names the likely trigger and the resume happens after a cool-down, not immediately.
Use this when
- an automated login hits a verify-it's-you or similar human-verification challenge
- the platform flags the session and the agent has no legitimate way through
- you need a clean stop-and-alert behavior for platform challenges
Not for this skill when
- a password that is simply wrong or expired (that's a credential-rotation problem)
- keeping a session alive with legitimate refresh logic (that's a session-management problem)
- official API access with proper partnership or credentials (that's an integration problem, not a browser-login problem)
- anything involving solving, bypassing, or working around the challenge (never do this; it risks the account)
Variant phrasings
- LinkedIn checkpoint on automated login, verify it's you screen, sequence stalled
- agent hit a human verification challenge and had no path through
- login flagged for verification, agent kept trying and got restricted
Why it happens
Platforms show checkpoints when the login looks unusual: new network, new device characteristics, or automation-like patterns. The challenge is designed for a human to complete, and there is no legitimate automated path through it. The sequence stalled because the agent had no behavior defined for this outcome, so it either froze or kept trying, and every extra attempt made the account look worse.
Edge cases
- checkpoints sometimes clear on their own if the account sits quiet; the cool-down doubles as this, but never probe the login to 'check'
- if checkpoints recur on the same account, the login environment is the problem: dedicated IP, consistent device profile, human-like pacing; fix the environment, not the challenge
- a checkpoint on one account can signal a wider flag on related accounts; check the others before resuming the whole fleet
- document the checkpoint in the account's history; a second checkpoint soon after the first means the trigger wasn't actually fixed
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_NE78VTFMqmtDAjQQpIpKPg