10.2 github.dev vs Codespaces

Why GH-900 splits github.dev from Codespaces

The January 2026 outline's next Domain 4 bullet is explain when to use the github.dev editor and how it differs from Codespaces. Domain 4 is still 10–15% of GH-900, but D4.5 is a discriminator skill: both products let you edit files from a GitHub repository, and both can look like Visual Studio Code in a browser tab. They are not the same environment. github.dev is the instant, free, browser-only editor. GitHub Codespaces is the cloud virtual machine and dev container from section 10.1. If a scenario needs a terminal, a debugger, or npm test, github.dev is the wrong answer even though you opened it with the same period key that feels like “cloud VS Code.”

github.dev introduces a lightweight editing experience that runs entirely in your browser. GitHub documents that the editor is currently in public preview. It is available to everyone for free on GitHub.com. You can open any repository, fork, or pull request. You must be signed in. Signed-out users, incognito windows that drop the session, and aggressive ad blockers are documented reasons it fails to open—not “the repository is public, so an anonymous editor should work.”

How to open github.dev

GitHub lists everyday entry points you should recognize on sight:

1. Press . (period) while browsing any repository or pull request to open github.dev in the same browser tab. Press > to open it in a new tab.
2. Change the URL hostname from github.com to github.dev and keep the rest of the path.
3. When viewing a file, open the edit-icon dropdown and choose github.dev.

If a local keyboard layout does not send . the way GitHub expects, the documented workaround is the hostname swap, not “install Visual Studio Code” and not “create a codespace first.” Creating a codespace is a different action on the repository Code dropdown. The period key does not provision a virtual machine.

github.dev still offers many Visual Studio Code benefits in the browser: search, syntax highlighting, and a Source Control view. Settings Sync can share your Visual Studio Code settings with this editor. None of that adds a terminal or a VM. The chrome looks familiar; the compute is missing on purpose.

Browser sandbox: no clone, no VM, no terminal

github.dev runs entirely in the browser’s sandbox. It does not clone the repository onto a virtual machine or onto your laptop disk as a persistent working tree. Most of the file and Git functionality comes from the GitHub Repositories extension. Your work is saved in the browser’s local storage until you commit. Commit regularly. A cleared cache, a different browser, or a lost session can drop uncommitted edits.

Because there is no associated compute, you will not be able to build and run your code and you will not get an integrated terminal. GitHub’s comparison table is blunt: terminal access is none. If you open the Run and Debug view or the Terminal, github.dev tells you those features are not available. That notification is the product working as designed, not a broken codespace.

Extensions are limited to web extensions—the subset of Visual Studio Code extensions written or updated to run in the browser. Those that can run appear in the Extensions view and can be installed; Settings Sync will also install compatible ones. Codespaces, by contrast, can use most extensions from the Visual Studio Code Marketplace, including many that need a Node runtime, a language server that shells out, or a local debugger. If the stem needs a heavyweight language extension that is not a web extension, pick Codespaces.

When to stay in github.dev, when to open Codespaces

Use github.dev when the job is read, edit, and commit and you want zero wait:

• Fix a typo in README.md, a docs page, or a workflow comment
• Review a pull request with highlighting and search without cloning
• Sketch a small code change you will commit from the Source Control view
• Edit on a Chromebook, a library kiosk, or a locked-down workstation that cannot install Visual Studio Code or Docker
• Avoid consuming Codespaces compute hours for a five-minute documentation change

Source control in github.dev is the Source Control view in the Activity Bar—the same mental model as Visual Studio Code, powered by the GitHub Repositories extension. You can create a new branch from the status bar; uncommitted changes are available on the new branch, and you can switch branches without stashing. Stage files, type a commit message, and choose Commit & Push. github.dev pushes to the branch on GitHub. You can then create a pull request from that view. To work on an existing pull request, browse to the pull request, press ., edit, and commit; those commits go directly to the branch (there is no extra push step after commit in that flow).

That workflow is enough when the exam stem never mentions running the app. The moment the stem says “run the test suite,” “open a shell,” “attach a debugger,” or “use an extension that needs a language runtime,” github.dev is the distractor.

When to use Codespaces instead

Choose GitHub Codespaces when you need a real development environment:

• Run tests, linters, or the application itself
• Use the terminal (npm install, pytest, gh, database CLIs)
• Debug with breakpoints in Run and Debug
• Install Marketplace extensions that are not web extensions
• Depend on a dev container so Node, Python, services, and forwarded ports match what the rest of the team uses
• Pair or concentrate for more than a few minutes of file editing, where a dedicated VM is worth the wait

Startup is slower because GitHub assigns a virtual machine and configures the container based on devcontainer.json. That setup can take a few minutes. The wait is the trade for compute. Codespaces is still usable from the browser, Visual Studio Code desktop, or GitHub CLI—the client is not what makes it different from github.dev. The dedicated VM, the terminal, and the dev container are.

Personal Codespaces usage still comes out of the monthly quota you learned in 10.1. github.dev does not consume that compute quota, because it has no compute. That is a legitimate reason to stay in github.dev for a docs tweak even when you could open a codespace.

Continue from github.dev into a codespace

GitHub documents a deliberate hand-off: start the workflow in github.dev and continue working in a codespace. If you try to access Run and Debug or the Terminal, you are notified that they are not available. Click Continue Working on… and select Create New Codespace to create a codespace on your current branch.

You must commit any changes first. github.dev’s buffer is browser local storage, not a disk on a VM that Codespaces can mount. Skipping the commit is the trap: uncommitted sandbox edits do not teleport into the new container. After the codespace exists, you have the terminal, debugger, Marketplace extensions, and the repository’s devcontainer.json from section 10.1. You do not “upgrade github.dev in place.” You create a codespace from the branch you committed.

Practical limits at Foundations level

github.dev is documented on Chrome (and other Chromium browsers), Edge, Firefox, and Safari—use current versions. Some keybindings differ by browser. Behind a corporate firewall you may need to allow Visual Studio Code CDN hosts and api.github.com. Extensions run in separate web workers. Intensive commit bursts can hit API rate limits; wait a few minutes and retry. None of those limitations secretly adds a terminal. They are reasons the lightweight editor sometimes needs a workaround, not reasons it became Codespaces.

Exam traps for D4.5

• The period key opens github.dev, not a codespace. Creating a codespace is a separate Code-dropdown (or CLI) action that assigns a VM.
• github.dev is free and instant; Codespaces has a quota and a container build that can take minutes.
• No terminal, no build, no run in github.dev. “Run the test suite in the period-key editor” is Codespaces.
• Web extensions only versus most Marketplace extensions.
• Must be signed in. Public preview is not an anonymous editor.
• Commit before Continue Working on… Local storage does not copy itself into a new codespace.
• github.dev does not clone onto a VM; Codespaces does clone into /workspaces on a VM.
• Do not confuse github.dev with GitHub Desktop, GitHub Mobile, GitHub Pages, or a self-hosted VS Code server.
• A Windows laptop still gets a Linux codespace if you continue into Codespaces; github.dev never had an OS to match in the first place because it has no VM.

If you can read a stem and answer “do they need a terminal or a debugger?” you have Domain 4’s github.dev-versus-Codespaces skill. Instant signed-in edits belong in github.dev. Anything that has to run belongs in Codespaces.