Windows Development Environments

The options for running a Wallabi development environment on Windows, and the tradeoffs between them.

WSL2 Development Environment

How it works:

  • Ubuntu Linux runs inside Windows. Your dev repo, dev server, and Claude Code all live on the Linux side of that boundary, which avoids most Windows filesystem overhead (NTFS, OneDrive synchronization, and Windows Defender scanning).
  • Claude’s sandbox can be configured, so auto-allow can be run safely (reducing frequent permission checks).

Best for:

  • The most native-feeling developer experience on Windows.
  • Fastest edit-build-debug cycle when the machine has sufficient CPU, RAM, and SSD performance.

Drawbacks:

  • Setup takes some work and has a few gotchas. Performance depends on following the recommended setup.
  • Some hardware will still struggle to run the dev server and Claude Code alongside your other applications. Available RAM and filesystem-heavy work are the usual limits.

→ Set up WSL2

GitHub Codespaces in Visual Studio Code

How it works:

  • A cloud container runs your repo, dev server, and Claude Code.
  • You start it from the Wallabi app, which creates the branch and wires up the credentials the container needs. The editor opens in your browser.
  • VS Code can then connect to the container from your machine via the Codespaces plugin. The connection is heavily optimized, so editing feels near native.
  • Running Claude with relaxed permissions is safer by default.

Best for:

  • Hardware that struggles to run dev server + claude + the rest of your apps.
  • Consistency and portability. The environment doesn’t depend on your local machine’s specs or settings.
  • The fewest setup steps of any option — nothing to install to get started.

Drawbacks:

  • Some interactions lag over the network until the connection warms up.
  • Needs a stable internet connection, which Wallabi development already required.

→ Set up Codespaces

Native Windows introduces a few challenges for a Claude-based Next.js development workflow:

  • The Next.js development server uses a lot of memory and hits the filesystem hard, especially on larger applications.
  • The Windows filesystem struggles with this workload, and is especially hindered by metadata-heavy operations, file watchers, and extra Windows services all competing over your developer directories.
  • Windows Defender and OneDrive sync both add significant overhead when they scan developer directories.
  • Claude Code supports Windows command line environments, but the experience is less seamless than Linux, and permission prompts come up more often.
  • Claude’s built-in sandbox doesn’t run natively on Windows, so running with relaxed permissions takes more work to do safely.

Windows Dev Drive (ReFS) has not meaningfully changed the DX for this use case in our experience.