Set Up a Vibe-Coding Development Environment with WSL2, GitHub, and Cloudflare

Perhaps you built a website with AI, but the next day, after switching computers or trying to edit a feature, you were unsure where to begin. The files still existed, but you did not know which version worked or how the site had been deployed.

This guide describes a basic workflow to avoid that situation: develop in WSL2 Ubuntu on Windows, record changes with Git, store the repository on GitHub, and connect Cloudflare so Git changes trigger builds and deployments.

It is one of the approaches used for ONSEMO, not the single correct solution for every project. Adapt it to your language, build system, and security requirements.

Before starting: the role of each tool

Tool	Purpose	Important distinction
WSL2 / Ubuntu	Linux development on Windows	Not complete isolation from Windows
Git	Track file changes locally	Commit working states for reliable comparisons
GitHub	Store and synchronize Git repositories remotely	Cloning code does not automatically recreate an environment
Codex CLI	AI-assisted code changes and verification	Review changed files and command permissions
Cloudflare	Build and deploy through Git integration	A successful push is not proof of production deployment

The intended flow looks like this:

Windows PC
   └─ WSL2 Ubuntu: development and local verification
       └─ Git commit → GitHub push
           └─ Cloudflare Git-integrated build and deployment
               └─ Verify the actual public URL

1. Prepare WSL2 Ubuntu on Windows

On Windows 11 or a supported Windows 10 version, open PowerShell as Administrator and install WSL. If WSL is already installed, check its current state first; do not delete or overwrite an existing distribution.

wsl --install

Follow the instructions, restart Windows if prompted, and launch Ubuntu. On its first start, you will create a Linux username and password.

In PowerShell, inspect the installed distributions and WSL version:

wsl --list --verbose
wsl --status

Now open the Ubuntu terminal and check your development tools. These commands run in Ubuntu, not PowerShell.

pwd
git --version
node --version
npm --version

If a command is not found, install the necessary tool. For example, on an Ubuntu installation without Git:

sudo apt update
sudo apt install git ca-certificates

Install a Node.js and npm version appropriate for the project. Checking .nvmrc or package.json first is usually safer.

A directory under the Linux user's home makes a convenient starting point:

mkdir -p ~/projects
cd ~/projects

Caution: installing WSL2 does not automatically block access to personal files on Windows. Access to mounted Windows drives such as /mnt/c depends on configuration and permissions. Codex's sandbox permissions are a separate layer to inspect.

Microsoft's official WSL installation guide

2. Manage code with Git and GitHub

Git records change history; GitHub hosts a Git repository remotely. Separating these roles makes troubleshooting easier.

First set the author name and email that appear on commits. The values below are placeholders. To reduce personal information in public repositories, consider GitHub's private commit email option.

git config --global user.name "YOUR_DISPLAY_NAME"
git config --global user.email "YOUR_COMMIT_EMAIL"

Create a repository on GitHub and find its URL under Code → SSH or HTTPS. To use SSH, prepare authentication and register the public key with your GitHub account. Do not overwrite an existing SSH key without checking it.

# Example if SSH authentication is already configured
ssh -T git@github.com
git clone git@github.com:YOUR_ACCOUNT/YOUR_REPO.git
cd YOUR_REPO

For a first-time connection, verify the server fingerprint against GitHub's official published fingerprints before accepting it. HTTPS cloning uses a different remote URL and may need a different authentication setup.

GitHub Docs — Cloning a repository

GitHub Docs — Testing your SSH connection

Record known-good states with commits

Before and after adding a feature or changing code, inspect the repository state:

git status
git branch --show-current
git log --oneline -n 5

Review the diff, then stage only the files related to this task and commit them:

git diff
git add README.md
git commit -m "docs: update project guide"
git push

README.md is only an example. Use the actual changed file names; if that file has not changed, there may be nothing to commit. Be careful not to stage another person's changes or credentials accidentally.

3. What if AI changes break a feature that used to work?

Even if you maintain careful project instructions, AI-generated changes can cause a formerly working feature to behave differently. Before repeatedly asking the AI to fix the issue, compare the current code with the last known-good commit.

# Review recent commits
git log --oneline -n 10

# Compare with a previously working commit
git diff GOOD_COMMIT_HASH HEAD -- path/to/file

Identify where the changes began and narrow down potential causes.

Practical tip: If analyzing Git history is difficult, ask Codex to "compare the last working commit with the current code, identify which files and lines changed, and explain likely causes; do not modify or restore any code yet." It can help inspect history, although tests are still needed to prove which change caused a bug.

Commands like git restore and git reset --hard can discard work. Avoid running them until you have backed up changes and understood the impact.

Remember that the last working state needs to have been committed. Git does not record every intermediate moment automatically.

I also wrote about the development experience behind this process.

4. Connect Codex CLI to project rules

With Node.js and npm available in a supported environment, you can install Codex CLI. Installation and login procedures change, so the official documentation should take precedence.

npm install -g @openai/codex
codex --version

Launch Codex from the directory of the project you want to work on. Asking it to read AGENTS.md and the current Git changes first, and restricting the scope of modifications, makes reviews easier.

cd ~/projects/YOUR_REPO
codex

AI-generated code is not automatically verified. Inspect changed files, build and test locally, and only then commit. Do not indiscriminately grant filesystem or network permissions.

Official OpenAI Codex documentation

5. Connect Cloudflare's Git-integrated deployment

This step assumes a web project that already builds successfully locally. A purely static HTML site and a Node.js application with build outputs may require different Cloudflare settings. Choose Workers or Pages based on your existing architecture.

In the Cloudflare dashboard, open the relevant project under Workers & Pages and connect its GitHub repository and production branch. Before changing an existing integration, inspect the connected repository, branch, and build configuration. Cloudflare may change menu labels and locations over time.

For Workers Builds, check:

Does the GitHub integration have permission to access the correct repository?
Is the production branch the intended branch (for example, main)?
Do the build command and output directory match the repository?
For Workers, does wrangler.jsonc or another supported configuration reference the right Worker and static assets?
Are environment variables and bindings configured safely within Cloudflare?

After integration, push locally verified changes and inspect Builds or Deployments in Cloudflare to confirm that the corresponding commit deployed successfully. This guide does not use a manual local deployment command. Cloudflare's internal use of deployment tools during its automated build is different from running deployment commands manually on a PC.

Cloudflare Docs — Workers Git integration

Cloudflare Docs — Workers static assets

6. GitHub push succeeded, but the site still looks unchanged

A successful Git push only proves that source code reached a remote repository. It does not prove that production has deployed the new version.

If the two results differ, check them separately. For an example of a problem that looked like GitHub authentication but was actually a mixture of networking and SSH configuration, see:

Step	What to check	Next action
1. GitHub	Is the commit on the right repository and branch?	Inspect commit and branch
2. Cloudflare	Did a build start for that exact commit?	Inspect Git integration and branch configuration
3. Build logs	Did build and deployment succeed?	Find the first failing log line
4. Worker URL	Does the new Worker respond?	Compare with the production domain
5. Custom domain	Does the domain point to the intended Worker?	Inspect domain and route mapping
6. Cache	Is an older response still being served?	Inspect headers and caching rules

Do not conclude that cache is the problem just because the site looks unchanged. Git connectivity, build targets, domain routes, and cache each need checking. Avoid changing DNS or deployment settings without identifying the cause.

When my WSL2 development environment later stopped because of memory pressure, I used the existing repositories to build a separate cloud development environment, with setup scripts, startup instructions, and Android SDK tools. That was about adding a second way to work, not simply abandoning local development.

7. Continue on a different computer

If the original computer is unavailable, you can retrieve source code committed to GitHub in another environment.

mkdir -p ~/projects
cd ~/projects
git clone git@github.com:YOUR_ACCOUNT/YOUR_REPO.git
cd YOUR_REPO

But you may still need a compatible Node.js version, package dependencies, environment variables, external service credentials, and local development tools. Read the project README and configuration, then run its appropriate installation, build, and test commands.

Do not solve this by committing secrets or an .env file to GitHub. Set up credentials in an authorized secure location in the new environment.

8. Checklist before publishing

[ ] WSL2 and Ubuntu are installed, and their versions are known.
[ ] Development and personal files have defined boundaries and permissions.
[ ] The intended GitHub repository is cloned; its branch and working tree are checked.
[ ] A known working state is recorded in Git.
[ ] Local build and tests pass, and changed files have been reviewed.
[ ] Cloudflare is connected to the correct repository, branch, and build settings.
[ ] The production deployment succeeded for the exact pushed commit.
[ ] The Worker URL and public custom domain show the expected result.
[ ] No secrets or personal files have entered the public repository.

Final thought: build an environment where work can continue

AI making code faster is the starting point of vibe coding. The real advantage comes from being able to find a working state after many changes, continue from a different computer, and verify the public result.

This guide is an overview of that complete workflow. Deeper troubleshooting for SSH authentication, WSL2 permissions, or Cloudflare deployment deserves its own verified follow-up guides.

To understand why I chose this setup in the first place, start with the development story: