ScreenshotNeo

BlogHow-to

How to Fix Cypress ENOENT No Such File or Directory Errors

Diagnose Cypress ENOENT errors by classifying the missing path, then fix specs, fixtures, binaries, caches, downloads, and Linux dependencies.

By the ScreenshotNeo team30 September 20268 min read

How to Fix Cypress ENOENT No Such File or Directory Errors

ENOENT means that a process tried to open a path that does not exist. In Cypress, the missing path may be a spec, fixture, generated download, Cypress executable, cache directory, or Linux shared library. Read the complete error first—especially the path after “no such file or directory”—and identify which process attempted to access it.

Use this sequence:

  1. Save the full stack trace, command, working directory, operating system, Node and Cypress versions, package manager, and whether the run is local or in CI.
  2. Classify the path: spec, fixture/generated file, screenshot/download/video, Cypress binary/cache, or host library.
  3. Check the relevant project configuration and environment variables.
  4. Re-run the smallest command that proves the classification, then apply the matching fix.

1. Capture the evidence before changing configuration

Do not treat every “Cypress ENOENT no such file or directory” message as a broken installation. Record the literal missing path and the operation that failed.

Classify the missing path before choosing a fix.
Classify the missing path before choosing a fix.
node --version
npx cypress version
npx cypress info
pwd
# Then run the same command that failed, for example:
npx cypress run --spec cypress/e2e/login.cy.js

Ask these questions:

  • Does the path name a spec under the project?
  • Does it name cypress/fixtures or a file created during a test?
  • Does it name cypress/downloads, cypress/screenshots, or cypress/videos?
  • Does it contain a Cypress version directory, cache path, or executable?
  • Does startup mention a missing .so shared library?

2. Cypress spec file not found

Cypress applies the --spec value together with the configured specPattern. The --spec path should be relative to the Cypress project folder. Supplying an exact path does not make a file eligible if it falls outside specPattern. See the Cypress configuration reference.

Check the project root and file

find cypress -type f | sort
npx cypress run --spec "cypress/e2e/login.cy.js"

Verify the command runs from the directory containing cypress.config.js (or cypress.config.ts), that the filename casing matches the filesystem, and that the file is checked into the CI checkout. In a monorepo, change into the package that owns the Cypress project or pass the correct project directory through your CI step.

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    specPattern: 'cypress/e2e/**/*.cy.{js,jsx,ts,tsx}'
  }
})

If the spec is stored elsewhere, either move it under the pattern or update the pattern to include it. Avoid broadening the pattern until you have confirmed the intended project root; a wrong working directory can make a valid path appear absent.

3. Cypress fixture or test-created file does not exist

Cypress uses cypress/fixtures by default. The folder can be changed with fixturesFolder or disabled. Check spelling, case, checkout contents, and the effective configuration. Cypress documents fixture organization and file access in Writing and organizing Cypress tests.

cy.fixture('users/admin.json').then((user) => {
  cy.request('/login', user)
})

cy.readFile('cypress/fixtures/report.json').should('have.property', 'status', 'ready')

cy.readFile() rereads the file during assertion retries, so it can wait for a report or other file to appear or finish changing. Ensure the writer uses the same absolute or project-relative location and completes its asynchronous write before the assertion deadline. Filesystem work that needs Node should run in a task:

// cypress.config.js
const { defineConfig } = require('cypress')
const fs = require('node:fs/promises')

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on) {
      on('task', {
        async writeReport({ path, contents }) {
          await fs.writeFile(path, contents, 'utf8')
          return null
        }
      })
    }
  }
})

// In a spec
cy.task('writeReport', {
  path: 'cypress/fixtures/report.json',
  contents: '{"status":"ready"}'
})
cy.readFile('cypress/fixtures/report.json').its('status').should('eq', 'ready')

4. Screenshot, download, or video path is missing

Cypress defaults downloads to cypress/downloads, screenshots to cypress/screenshots, and videos to cypress/videos. Configuration can change each path. During cypress run, trashAssetsBeforeRuns defaults to true, so contents of configured asset folders can be cleared before a run.

Generated screenshots and videos mirror the unique portion of the spec directory structure. A guessed path can therefore be wrong when the set of specs in a run changes. Read the resolved path from the screenshot result or Node events instead of constructing it manually.

cy.screenshot('checkout')

// cypress.config.js
module.exports = {
  e2e: {
    screenshotsFolder: 'artifacts/screenshots',
    videosFolder: 'artifacts/videos',
    downloadsFolder: 'artifacts/downloads'
  }
}

If another process expects an artifact, make that process consume the path reported by after:screenshot or after:spec. Also check whether CI cleanup, parallelization, or a changed spec name placed the file under a different nested directory.

5. Cypress binary not found in cache

Cypress downloads a platform-specific binary during package installation. If the install hook was skipped, the download failed, or CI restored an incomplete cache, cypress run and cypress verify can report an ENOENT or a “Cached Cypress Binary Could not be found” error. Follow the official common error guidance and CI guide.

# Reinstall dependencies with the install scripts enabled
rm -rf node_modules
npm ci
npx cypress verify
npx cypress cache path
npx cypress cache list

Do not assume that caching node_modules also provides a valid Cypress binary. Cache the package manager data and Cypress binary according to your CI provider’s cache mechanism, then run npx cypress verify in the job that executes tests. Add cache-path and cache-list diagnostics to failed jobs.

Custom cache and executable settings

CYPRESS_CACHE_FOLDER must point to a directory that exists when Cypress launches. CYPRESS_RUN_BINARY must point to an already unzipped Cypress executable, not merely the archive or its parent directory.

echo "$CYPRESS_CACHE_FOLDER"
echo "$CYPRESS_RUN_BINARY"
test -n "$CYPRESS_CACHE_FOLDER" && test -d "$CYPRESS_CACHE_FOLDER"
test -n "$CYPRESS_RUN_BINARY" && test -x "$CYPRESS_RUN_BINARY"
npx cypress verify

When unzipping a downloaded binary, inspect the resulting tree. Some archives create an additional top-level cypress directory, changing the executable path. Compare local and CI environment values without printing secrets.

6. Linux runtime dependency is missing

If the error occurs while Cypress launches and names a shared library, distinguish a missing library from a missing Cypress executable. Cypress’s troubleshooting guidance recommends a binary smoke test and ldd.

npx cypress verify
# Use the executable path printed by Cypress, then:
ldd /path/to/Cypress | grep 'not found'

Install the operating-system packages corresponding to every dependency marked not found, or run in a Cypress-supported Docker image that includes the required libraries. This branch does not fix a missing fixture or spec; only use it when startup evidence points to host dependencies.

7. Diagnostic decision tree

Missing path contains Likely branch First check
cypress/e2e, .cy.js, .cy.ts Spec discovery Project root, file casing, specPattern, and --spec relativity
cypress/fixtures or generated report Fixture/test file Writer path, async completion, fixture configuration, and checkout contents
downloads, screenshots, videos Generated asset Configured folders, cleanup, nested spec path, and event-reported path
Cypress version directory or executable Binary/cache Install hook, cache restoration, CYPRESS_CACHE_FOLDER, and CYPRESS_RUN_BINARY
.so library during launch Linux runtime Smoke test and ldd output

8. CI-specific checks

  1. Print OS, Node, Cypress version, package manager, working directory, and the effective Cypress cache path.
  2. Confirm the checkout includes the spec and fixture files, including case-sensitive names.
  3. Run dependency installation with Cypress’s install scripts enabled.
  4. Restore the Cypress binary cache before cypress run, then execute npx cypress verify.
  5. Check that the CI job’s working directory matches the project containing the Cypress config.
  6. For Linux containers, run the smoke test and inspect ldd only if launch fails on a library.

9. Performance, reliability, and cost considerations

Use the narrowest --spec while diagnosing to reduce startup and feedback time. Keep cache keys tied to the Cypress version, operating system, architecture, and lockfile so a restored cache cannot point at an incompatible binary. Avoid writing test artifacts to shared locations when parallel jobs can race; include a run or shard identifier in generated paths. Let Cypress retry cy.readFile() for files that are expected to appear, but set a bounded command timeout and fail with the writer’s path when production code never creates the file. In CI, artifact retention and cache storage can add cost, so retain only the logs and screenshots needed to diagnose a failed run.

10. Common errors and fixes

Error pattern Cause Fix
Spec supplied with --spec is not found Path is outside specPattern or relative to the wrong directory Run from the Cypress project root and align the pattern and path
Fixture file does not exist Wrong folder, spelling, case, or checkout Check fixturesFolder, repository contents, and exact path
Generated report is missing Writer has not completed or writes elsewhere Use cy.task(), await the write, and let cy.readFile() retry
Screenshot/download path is absent Assets were cleaned or stored under a nested spec path Inspect configured folders and event callbacks
Cached Cypress Binary Could not be found Install hook skipped or cache not restored Run installation with scripts, restore a valid binary cache, and verify
Custom binary ENOENT Environment variable points to an archive, parent directory, or nonexistent path Point CYPRESS_RUN_BINARY at the executable and ensure cache folder exists
Linux launch reports a missing library Host dependency is absent Use ldd to identify “not found” libraries and install them or use a Cypress image
A clean capture pipeline removes overlays before producing the image.
A clean capture pipeline removes overlays before producing the image.

Or skip the browser setup

If your goal is to capture pages for documentation, visual checks, or an automation workflow, ScreenshotNeo returns a screenshot or PDF from one GET request. It removes cookie and consent banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, failed loads, and cache hits are not billed. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients.

See the ScreenshotNeo API documentation for all options.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

The free plan includes 1,000 screenshots each month with no card. Paid plans start at $5 for 3,000 shots, and every feature is available on every plan. Create a free ScreenshotNeo account.

FAQ

Does ENOENT always mean Cypress is not installed?

No. It only says that the requested path was absent. The path and failing process distinguish a project file, generated asset, binary, cache, or Linux library problem.

Why does a spec work locally but fail in CI?

CI commonly uses a different working directory, case-sensitive filesystem, checkout contents, Cypress cache, operating system, or install-script policy. Compare those values before changing the test.

Should I delete the Cypress cache?

Only after confirming the cache is stale or incomplete. First inspect the configured cache path and run npx cypress verify; deleting a valid cache adds a download without fixing a wrong project path.

Can I use cy.readFile() for a file created during a test?

Yes. Cypress rereads it during retries, which allows a file to appear or change. Put Node filesystem operations in cy.task() and make the writer finish before the assertion timeout.