Cypress GUI run against remote dev (WSL2, Codespaces, Docker, etc)

[NicholasBoll]

What would you like?

The Cypress GUI running against a remote development environment. Not using Xwindow forwarding or messing with complicated settings. Run the Cypress GUI pointing to a remote Cypress dev process.

Example:

On remote development environment (WSL2, Codespaces, Docker, etc).

cypress dev

This command would set up a cypress dev server for the GUI to connect to. This server would be responsible for all the requests the Cypress GUI usually asks for (test files, reloading when files are updated, bundling, etc).

The Cypress GUI can be started from the local environment either via cypress open or a different command. This method requires Cypress to be installed globally on the local machine. From here, the user has the ability to point the GUI to a remote development environment.

Why is this needed?

It is very difficult to set up x-window forwarding and it can be very slow streaming pixels from a remote machine. It is much more efficient to stream text and commands. Remote development is getting more popular with the release of more development environment solutions like Codespaces. In my own workflow, I use WSL2. In remote development, Cypress is the most painful tool to use. There are tutorials for getting X servers working, but even when the do work, the remote rendering looks terrible with HiDPI screens.

I've gotten by with cloning the repository I'm working with and starting Cypress against the local clone. The problem with this is it is easy to forget to copy/paste local Cypress spec file changes to the remote environment. The Cypress GUI seems to be tied to the local file system. VSCode has solved this problem making remote development seamless. I can install a Remote SSH, Remote WSL, or Remote Containers or connect to a Codespace, running a local version of VSCode and connect to a remote VSCode (server).

This would make remote development environments work much better with Cypress development.

Other

No response

[levymp]

+1 for adding the ability for remote development...
would be great to have a command like the following:
cypress open --e2e --skip-gui
Then open the remote machine's instance of cypress in chrome to view/iterate on tests similar question has been asked here: https://stackoverflow.com/questions/53861190/using-cypress-test-runner-on-remote-development-server and here: https://stackoverflow.com/questions/60286652/running-the-cypress-test-runner-remotely

[cypress-app-bot]

This issue has not had any activity in 180 days. Cypress evolves quickly and the reported behavior should be tested on the latest version of Cypress to verify the behavior is still occurring. It will be closed in 14 days if no updates are provided.

[Kaiden42]

+1
X11 forwarding the browser from the remote machine is painfully slow and crashes multiple times a day 😕

[Jack-G-Smith]

+1

[spaque99]

+1. I would love this feature

[Xvpher]

+1 Any updates on this feature?

[theunkn0wn1]

+1
Several of our developers run the website under test on a remote system they SSH into.
we just discovered npx cypress open doesn't work over a ssh shell as no UI opens.

for these developers, its not possible to run cypress locally.

[arminus]

+1
would be nice to have

[ShaneBurkhart]

+1 I would like this too. We develop on remote servers.

[DanielDaCosta]

+1 would be nice to have

[stordahl]

+1 on this

[ericd7]

+1 would love this to be an option.

[hd-o]

FYI Playwright implements this with the --ui-host and --ui-port options:
https://playwright.dev/docs/test-ui-mode#docker--github-codespaces