A Cypress captcha problem is a runtime problem before it is a solving problem. Your spec code runs inside the browser under test, so the Node client that talks to the solver cannot live there. Register it as a task in cypress.config.js instead, call that task from the spec, and write the token into the hidden field yourself. Three things make it work: the task, a raised timeout, and a direct DOM write rather than a Cypress click. This guide covers all three.<\/p>\n
# The client only ever runs in the Node half of Cypress.\nnpm install --save-dev capskip<\/pre>\n<\/div>\nWhy the solve cannot go in the spec<\/h2>\n
Cypress splits into two processes and this is the whole reason the naive version fails. Your spec file is bundled and executed inside the browser, next to the application. Everything in cypress.config.js runs in Node, outside it.<\/p>\n
Requiring the solver client at the top of a spec therefore pulls a Node HTTP client into a browser bundle. Even when the bundler lets that through, the browser then blocks the call: a request from your app’s origin to 127.0.0.1 on port 8080 is cross origin, and the solver is not sending CORS headers to make it legal.<\/p>\n
Cypress gives you two doors into Node, and both are fine:<\/p>\n
One function, registered once, available to every spec.<\/p>\n
\/\/ npm install --save-dev capskip\nconst { defineConfig } = require('cypress');\nconst { CapSkip } = require('capskip');\n\n\/\/ Local mode. Point host at a server IP to share one solver.\nconst solver = new CapSkip({ host: '127.0.0.1', port: 8080 });\n\nmodule.exports = defineConfig({\n \/\/ 60000 is the default, and a v2 solve can outlast it.\n taskTimeout: 180000,\n\n e2e: {\n setupNodeEvents(on) {\n on('task', {\n async solveRecaptcha({ sitekey, url }) {\n const result = await solver.recaptcha(sitekey, url);\n return result.code; \/\/ the token\n },\n });\n },\n },\n});<\/pre>\n<\/div>\nOne rule about tasks that costs everyone an hour the first time: a task must return a value or null, never undefined. Forget the return statement and Cypress fails the command with a message about the task returning undefined, which reads like the solver broke when the solver was never called.<\/p>\n
Step 2: call the task and inject the token<\/h2>\n
Read the sitekey off the page, hand it to the task, and put the answer where the widget would have put it.<\/p>\n
\n\/\/ cypress\/e2e\/login.cy.js\nit('logs in through the reCAPTCHA', () => {\n cy.visit('\/login');\n\n cy.get('[data-sitekey]')\n .invoke('attr', 'data-sitekey')\n .then((sitekey) => {\n const url = 'https:\/\/example.com\/login';\n\n cy.task('solveRecaptcha', { sitekey, url }).then((token) => {\n \/\/ The widget writes into a hidden textarea. Do the same.\n cy.document().then((doc) => {\n doc.getElementById('g-recaptcha-response').value = token;\n });\n });\n });\n\n cy.get('button[type=submit]').click();\n cy.contains('Welcome back');\n});<\/pre>\n<\/div>\nNote the DOM write. The response field is a hidden textarea, and Cypress refuses to type into an element it considers invisible, so the obvious version with a get and a type call fails on visibility before it ever gets near the token. Going through cy.document sidesteps that, exactly as the widget’s own JavaScript would.<\/p>\n
If the widget div carries a data-callback attribute, invoke that function with the token instead of clicking the submit button. Pages built that way never wire up a normal form submit, so the click does nothing.<\/p>\n
The timeout that actually bites is taskTimeout<\/h2>\n
This is the failure that gets blamed on the solver most often, and the fix is one line in the config.<\/p>\n
Cypress gives a task 60 seconds<\/strong> by default. A reCAPTCHA v2 job is not ready for the first 15 to 20 seconds, v3 takes 10 to 15, and a busy machine can stretch either. When the ceiling hits, Cypress kills the command and the test fails with a timeout that names your task, not the CAPTCHA.<\/p>\nThe trap next to it is raising the wrong number. Most Cypress timeout advice points at defaultCommandTimeout, which is 4000 milliseconds and governs DOM commands. It has no effect on a task. Three values matter here and they are all separate:<\/p>\n