GitHub Browser Editor: What github.dev Can Do, What It Cannot, and When You Need Codespaces Instead

The GitHub browser editor is github.dev: press the full stop key on any repository or pull request, or change github.com to github.dev in the URL, and the repository opens in a Visual Studio Code interface that runs entirely in the browser. It is free for everyone, it can read, edit, search and commit across the whole tree, and it has no terminal, no runtime and no way to execute anything, because there is no machine behind it. That single fact decides when to use it: edits, reviews, documentation and small fixes belong in github.dev; anything that needs to run a build, a test or a dev server belongs in Codespaces, which is the same editor attached to a cloud machine that bills by the hour.

People find this feature by accident, by pressing a key on a repository page, and then wonder what they have opened and how far it goes. This is the map: what the editor is, what it does well, where it stops, and the workflow that gets the most out of it without paying for a machine you do not need.

Table of contents

• Opening it, and what you are looking at
• What it does well
• What it cannot do, and why
• The workflow that fits
• When to move to Codespaces
• What the browser editor is not: a place to deploy from
• How this fits the rest of the stack
• FAQ

Opening it, and what you are looking at

• On any repository, branch, file or pull request page, press . and the editor opens on that context.
• Or edit the URL: github.com/owner/repo becomes github.dev/owner/repo.
• Or use the green Code button on the repository page and choose to open in github.dev.

What loads is the web build of VS Code with the GitHub Repositories extension, which fetches files on demand through the GitHub API rather than cloning. There is no local copy and no disk. The file explorer, the editor tabs, the search across files, the command palette and the source control panel all work as they do on the desktop, and the settings you sync to your GitHub account follow you in.

What it does well

• Multi-file edits with a single commit. Change a config, a README and a workflow file, review the diff in the source control panel, write a message, commit. On the desktop web UI that is three separate edits and three commits.
• Branch and pull request creation. Commit to a new branch and open the pull request from the editor, without leaving the page.
• Reading a pull request as code. Open a PR in github.dev and the changed files are shown in a diff view with the full repository context around them, which is easier to navigate than the web diff for large changes.
• Search across the repository. Full-text search across every file, with regular expressions, the way the desktop editor does it.
• Syntax highlighting, IntelliSense for languages that run in the browser, and extensions that do not need a runtime. Markdown preview, themes, keybindings, linters that are pure JavaScript.
• Working from a device with no toolchain. A tablet, a locked-down work laptop, a borrowed machine. The editor needs a browser and a login.

What it cannot do, and why

There is no compute. Everything that needs a process is absent.

• No terminal. No npm install, no git log beyond what the API exposes, no shell.
• No running the code. No dev server, no tests, no build, no debugging. The Run button is not there.
• No extensions that need a backend. Language servers for compiled languages, container tooling, database clients. The extension marketplace inside github.dev only shows extensions that can run in the browser.
• No Git operations beyond commit and branch. No rebase, no cherry-pick, no stash, no history rewriting. Conflicts in a pull request cannot be resolved here if they require merging.
• No file uploads over a certain size, and no binary editing.

This is not a limitation to work around; it is the design. The editor is a client for the GitHub API with a good text editor in front of it, and the API does not run code.

The workflow that fits

1. Open the repository in github.dev for the change you can make by reading: the typo in the docs, the value in the config, the missing case in the switch statement you can see is wrong.
2. Make the edit, check the diff, commit to a branch, open the pull request.
3. Let continuous integration run the tests. That is the compute you did not have in the browser, and it runs on every push whether or not you ran anything locally.
4. If CI passes, merge. If it fails, the failure log tells you whether the change needs a machine to fix, and that is when you move to the next section.

For a surprising share of changes, that loop never needs a machine. Documentation, configuration, workflow files, small logic fixes with existing test coverage, dependency version bumps: all of them are edits that CI verifies. The browser editor plus a CI pipeline is a complete workflow for that class of change.

When to move to Codespaces

Codespaces is the same VS Code interface attached to a container running on a cloud machine, with a terminal, a runtime, port forwarding for a dev server, and the full extension set. It is what github.dev becomes when you need to run something. The switch is one command from inside github.dev, Continue Working in Codespaces, and the editor state carries over.

The difference is that a codespace is a machine and bills as one, by the core-hour while it runs, with a monthly free allowance on personal accounts that covers a good deal of occasional use. The rule that keeps the bill small: use github.dev for everything that does not need to run, open a codespace only when it does, and stop it when you are done. A codespace left running over a weekend is the most common way the free allowance disappears.

What the browser editor is not: a place to deploy from

Neither github.dev nor a codespace is a hosting environment. A dev server in a codespace is reachable through forwarded ports for as long as the codespace runs, which makes it fine for showing a colleague and wrong for anything a user should reach. Deployment is a separate step, and the good version of it starts from the same place the browser editor does: the repository. A host that watches the repository builds on every push to the main branch and serves the result at a URL that does not depend on any editor being open.

That pairing is the complete loop for a small project with no local toolchain at all: edit in the browser, commit, CI tests, merge, the host deploys, the site is live. No machine of your own in the path, and the only compute you pay for is the thing that actually serves users.

How this fits the rest of the stack

The last step in that loop is what deploying from GitHub on RunxBuild does: connect the repository, and every push to the branch you choose builds and goes live with the build log and the runtime log in the dashboard, for a static site or a service. The RunxBuild hosting calculator shows what that costs beside a database, which for a project edited entirely in the browser is the only infrastructure line there is.

Useful related references:

• Cursor vs GitHub Copilot: Editor-First or Plugin-First
• Undo Commit on GitHub: What You Can Do in the Browser and What Needs the Terminal
• GitHub Pages SEO: What You Can Fix and What You Cannot
• Deploying from GitHub on RunxBuild

FAQ

How do I open the GitHub browser editor?

Press the full stop key on any repository, file or pull request page, or replace github.com with github.dev in the URL. The repository opens in a VS Code-style editor running in the browser, free for all GitHub users.

Can I run code in github.dev?

No. github.dev has no terminal, no runtime and no compute; it is an editor over the GitHub API. To run a build, tests or a dev server in the browser, open the repository in Codespaces, which attaches the same editor to a cloud machine.

What is the difference between github.dev and Codespaces?

github.dev is a free, browser-only editor with no machine behind it: read, edit, search and commit. Codespaces is the same editor connected to a container on a cloud VM with a terminal, runtime, port forwarding and full extensions, billed by the core-hour with a monthly free allowance on personal accounts.

Can I commit and open a pull request from the browser editor?

Yes. The source control panel stages changes across multiple files, commits with a message to the current branch or a new one, and offers to open a pull request. Rebase, cherry-pick and conflict resolution that requires merging are not available.

Can I deploy a site from github.dev or Codespaces?

Not directly; neither is a hosting environment. Codespaces can forward a dev server port temporarily. For a live site, connect the repository to a host that builds and deploys on every push, so the deployment does not depend on an editor being open.