DEV Community

Cover image for How to Use GitHub Codespaces in Cursor, Windsurf, VSCodium, and Other VS Code Forks
Nirbhay Hiwse
Nirbhay Hiwse

Posted on Originally published at linkedin.com

How to Use GitHub Codespaces in Cursor, Windsurf, VSCodium, and Other VS Code Forks

#vscode #github #cursor #opensource

GitHub Codespaces is a great way to move your development environment into the cloud.

The container, dependencies, source code, and compute all live remotely, while your local machine becomes the client you use to work on the project.

For standard Microsoft VS Code, GitHub provides a dedicated Codespaces experience.

But things get more complicated when your editor is Cursor, Windsurf, VSCodium, Code-OSS, or another VS Code-based editor.

That is where I kept running into the same problem.

The cloud environment was already working.

GitHub Codespaces was working.

The repository was working.

SSH was working.

The part that was missing was the glue between GitHub Codespaces and the editor.

So I ended up building that glue.

This article explains the underlying workflow first, and then shows how I use Antigravity Codespaces Pro to simplify it.

The actual problem

Let's say your development setup looks like this:

GitHub Repository
       ↓
GitHub Codespaces
       ↓
Remote Linux container
       ↓
SSH connection
       ↓
Cursor / Windsurf / VSCodium
Enter fullscreen mode Exit fullscreen mode

The important part is that Codespaces itself isn't the difficult piece.

GitHub already provides CLI commands for listing, creating, stopping, rebuilding, SSHing into, and forwarding ports from Codespaces. GitHub's CLI also supports generating OpenSSH configuration for Codespaces.

The problem starts when you want a non-Microsoft VS Code-based editor to behave like a first-class Codespaces client.

Then the workflow can become:

  1. Open GitHub.
  2. Find the Codespace.
  3. Make sure it is running.
  4. Install/authenticate GitHub CLI.
  5. Configure SSH.
  6. Find the correct Codespace host.
  7. Open Remote SSH.
  8. Select the host.
  9. Wait for the remote server.
  10. Start working.

It works.

But it is a lot of ceremony for something that should feel like:

Open editor → select cloud workspace → code.

How GitHub Codespaces actually works here

The first thing to understand is that a Codespace is a remote development environment.

GitHub's own CLI exposes commands such as:

gh codespace list
Enter fullscreen mode Exit fullscreen mode

to list Codespaces, and:

gh codespace ssh -c <codespace-name>
Enter fullscreen mode Exit fullscreen mode

to open an SSH session.

You can also generate OpenSSH configuration with:

gh codespace ssh --config
Enter fullscreen mode Exit fullscreen mode

which is useful for tools that integrate with OpenSSH. GitHub CLI documents this specifically as a way to make Codespaces behave more like normal SSH hosts for tools such as ssh, scp, rsync, and sshfs.

That is the key idea.

You don't need the browser to be your only interface.

You can use the standard SSH layer as the bridge between the editor and the cloud environment.

Step 1: Install GitHub CLI

Install GitHub CLI for your operating system and authenticate:

gh auth login
Enter fullscreen mode Exit fullscreen mode

GitHub documents GitHub CLI as the command-line interface for working with GitHub and Codespaces.

Then verify your Codespaces are visible:

gh codespace list
Enter fullscreen mode Exit fullscreen mode

You should see your available environments.

Step 2: Connect to a Codespace through SSH

For a direct terminal connection:

gh codespace ssh -c <codespace-name>
Enter fullscreen mode Exit fullscreen mode

GitHub notes that the Codespace must have an SSH server available. The default dev container includes an SSH server; custom images may need the SSHD feature added to devcontainer.json.

For example:

{
  "features": {
    "ghcr.io/devcontainers/features/sshd:1": {
      "version": "latest"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

The exact container setup depends on how your Codespace is built.

Step 3: Generate SSH configuration

This is where the workflow becomes useful for editors such as Cursor and other Remote-SSH-compatible tools.

GitHub CLI supports:

gh codespace ssh --config
Enter fullscreen mode Exit fullscreen mode

You can use its generated OpenSSH configuration with your local SSH config. GitHub provides this capability specifically so Codespaces can integrate with standard OpenSSH tooling.

Conceptually, you end up with:

Local editor
     ↓
Remote SSH
     ↓
OpenSSH configuration
     ↓
GitHub CLI
     ↓
Codespaces
     ↓
Remote container
Enter fullscreen mode Exit fullscreen mode

That means the editor doesn't need to understand every Codespaces-specific detail itself.

It can communicate through the normal remote-development stack.

Why Cursor users often end up doing this manually

This isn't just theoretical.

Developers have been sharing Cursor + Codespaces SSH workarounds involving GitHub CLI, gh codespace ssh, generated SSH configuration, and Remote-SSH. Cursor community discussions also contain requests around Codespaces support and reports of connection problems.

The result is usually a manual chain of configuration.

For one Codespace, that may be fine.

For five or ten Codespaces, it starts becoming repetitive.

For multiple GitHub accounts, it becomes even more interesting.

The multiple-account problem

GitHub CLI supports multiple accounts, including multiple accounts on GitHub.com, and provides gh auth switch for changing between them.

That works, but there is an important workflow problem.

Suppose you have:

Personal GitHub
Work GitHub
Client GitHub
Open Source GitHub
Enter fullscreen mode Exit fullscreen mode

and Codespaces running under several of those accounts.

Now your workflow isn't simply:

Start Codespace → Connect
Enter fullscreen mode Exit fullscreen mode

It becomes:

Which account?
Which Codespace?
Is the correct CLI account active?
Which SSH host?
Which repository?
Enter fullscreen mode Exit fullscreen mode

The technical system works.

The human workflow becomes the bottleneck.

That distinction matters.

The approach I took

Instead of making developers repeatedly jump between browser sessions, CLI profiles, and SSH configuration, I wanted the editor to expose Codespaces as workspace objects.

So I built Antigravity Codespaces Pro around that idea.

The current project supports:

  • Cursor
  • Antigravity IDE
  • VS Code / Code-OSS
  • Windsurf
  • VSCodium

and provides a dashboard for managing Codespaces rather than treating every environment as a manual SSH setup.

The extension currently supports:

Quick Connect
Multi-account management
Start / Stop
Rebuild
SSH configuration
Port discovery
Workspace dashboard
Remote environment monitoring
AI-agent keepalive settings
Enter fullscreen mode Exit fullscreen mode

The current extension metadata is version 5.0.8 and includes keywords around GitHub Codespaces, Cursor, remote development, SSH, cloud IDEs, AI agents, and developer tools.

Quick Connect

One of the simplest ideas in the extension is a quick launcher.

The default shortcut is:

Alt + C
Enter fullscreen mode Exit fullscreen mode

The goal is to make a Codespace feel closer to a local project.

Instead of searching through browser tabs:

Alt + C
↓
Search workspace
↓
Enter
↓
Connect
Enter fullscreen mode Exit fullscreen mode

The launcher is designed to search across the connected Codespaces and prioritize active environments.

Why start/stop controls matter

There is also a resource-management problem with cloud development.

A Codespace that remains running continues consuming compute resources.

GitHub's documentation states that running Codespaces incur CPU charges, while stopped Codespaces continue to incur storage costs.

GitHub also measures Codespaces compute in core-hours, where the machine's core count affects how many core-hours are consumed.

So:

Start → work → stop
Enter fullscreen mode Exit fullscreen mode

isn't just a UI preference.

It can be a useful cost-management habit.

That's why the dashboard exposes lifecycle controls instead of making you return to the GitHub website every time.

Port forwarding is another hidden source of friction

A cloud development environment is not very useful if your application is running remotely and you have no easy way to access it locally.

GitHub CLI supports port forwarding with:

gh codespace ports forward 8000:8000 -c <codespace-name>
Enter fullscreen mode Exit fullscreen mode

and provides commands for inspecting and changing port visibility.

For a web developer, this matters a lot.

Your application might be running at:

3000
5173
8000
8080
Enter fullscreen mode Exit fullscreen mode

inside the Codespace.

A good remote-development workflow should make those ports discoverable without another round of manual commands.

That is one of the reasons the extension includes forwarded-port discovery.

What this setup is actually useful for

This workflow is especially useful when:

  • your laptop is not powerful enough for your full development environment
  • you switch between machines
  • your repositories require heavy dependencies
  • you work with AI coding agents
  • you maintain separate GitHub accounts
  • you use Cursor or another VS Code fork
  • you want reproducible Linux environments
  • you want your development environment to stay close to the repository

You don't need all of these use cases.

Even one of them can justify a cloud development environment.

A simple mental model

Think of the system as five layers:

┌──────────────────────────────┐
│          Your IDE            │
│ Cursor / VS Code / Windsurf  │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│       Remote Development     │
│      SSH / Remote-SSH        │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│         GitHub CLI           │
│    Codespaces + Auth         │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│      GitHub Codespaces       │
│      Remote Linux VM         │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│     Repository / Container   │
│   Code + Dependencies + App  │
└──────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

Once you understand this architecture, the setup stops feeling mysterious.

Where Antigravity Codespaces Pro fits

I didn't build it to replace GitHub Codespaces.

GitHub Codespaces is still the cloud environment.

I built the extension to make the client-side management workflow less repetitive.

That's an important distinction.

The project is open source and MIT licensed.

Repository:

Nir-Bhay/antigravity-codespaces

Final takeaway

GitHub Codespaces is already a very capable remote-development system.

The friction appears when you want to use it outside the most straightforward Microsoft VS Code workflow.

The underlying technologies are already there:

GitHub Codespaces
+
GitHub CLI
+
OpenSSH
+
Remote-SSH
Enter fullscreen mode Exit fullscreen mode

The missing piece is often the developer experience around them.

That was the problem I wanted to solve.

Not another cloud IDE.

Just a better way to get from:

I have a Codespace

to:

I'm coding in it.

What does your current GitHub Codespaces workflow look like?

Do you use the browser, VS Code, Cursor, SSH, GitHub CLI, or something else?

Top comments (1)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.