GitHub1s: Reading GitHub Repositories Inside a Browser VS Code
One second to read GitHub code with VS Code.
At a glance
- What is it?
- GitHub1s turns a GitHub URL into a VS Code workspace by swapping the domain, and it works best as a read-only browsing tool for public repositories. The OAuth token path for private repos and the Gitpod handoff for editing are where the design gets more interesting and more constrained.
- Who is it for?
- Adopt GitHub1s if you need to skim a public repository with VS Code's file tree, search and syntax highlighting without cloning it, and treat the Gitpod button as the point where reading turns into editing. Do not adopt it as a replacement for a local checkout, as a code-hosting service, or as a way to keep private repository credentials in a server-side tool.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The URL swap that defines the whole project
GitHub1s solves a narrow problem: reading a repository on GitHub without cloning it, and without giving up the editor affordances that make large codebases navigable. The README states the mechanism plainly. Add 1s after github in the address bar and press Enter. The example given is https://github1s.com/microsoft/vscode, which is the VS Code repository rendered inside a browser VS Code instance. The same pattern is documented for gitlab1s.com and npmjs1s.com.
That is the entire onboarding surface for a reader. There is no account, no install, and no repository import step. The audience is anyone who lands on a GitHub file page, wants to jump to a definition or scan a directory tree, and does not want to wait for git clone. It is a reading tool first. The README is explicit that editing files, running Docker containers and creating pull requests happen through a separate Gitpod integration, not through the github1s.com view itself.
How the browser VS Code instance is assembled
The README links to a separate document, docs/guide.md, for how it works, and does not reproduce the pipeline in the main file. What can be confirmed from the repository layout and the README is the shape of the deployment: a web front end that loads a VS Code workbench in the browser, plus a file-fetching layer that talks to GitHub. The private repository section describes the data flow for authenticated requests. The token is stored only in your browser and is only sent to GitHub when fetching your repository's files. That sentence rules out a server-side proxy holding your credentials, which is a meaningful design decision for anyone evaluating whether to paste a token into a third-party page.
The Gitpod path is a handoff rather than an in-page feature. The README describes a Develop your project on Gitpod button in the status bar and a Command Palette entry, GitHub1s: Edit files in Gitpod, reachable with the default Ctrl+Shift+P shortcut. Editing, containers and pull requests all happen on Gitpod's side. GitHub1s is the viewer that gets you there.
Running it locally and the two build modes
Local development is documented in two variants, and the difference matters for how long your first build takes. The lighter path is a clone, npm install, then npm run watch. The README says the CLI opens http://localhost:8080 once the build completes, and that http://localhost:8080/conwnet/github1s is the fallback URL if it does not.
The heavier path is the full VS Code build. The README points to the same prerequisites listed for contributing to VS Code and warns that you should be able to build VS Code locally before using watch mode. Verification is a single command, npm run build:vscode, followed by npm run watch-with-vscode. There is also a Docker route through the Remote-Containers extension: install the plugin, open the Command Palette, choose Remote-Containers: Clone Repository in Container Volume, enter https://github.com/conwnet/github1s.git or a fork, and pick either Create a unique volume or Create a new volume. After the container connects, the same npm install and npm run watch commands apply. Formatting is a separate npm run format script, which the README says uses prettier.
Private repositories and where the token lives
Non-public repositories require an OAuth token. The README says to click the icon near the bottom of the left-hand row of icons, and that the dialog prompts for the token and can take you to your GitHub settings page to generate one if needed. The stored token stays in the browser and is sent to GitHub when files are fetched.
This is the part of the design worth pausing on. The privacy claim is narrow and specific: browser storage, and transmission to GitHub rather than to github1s.com. It does not say the token is encrypted at rest, and it does not describe a scope recommendation. If you are evaluating GitHub1s for anything beyond public code, the token you generate is the thing you control, and the README leaves scope selection to GitHub's own settings page. The browser extension ecosystem around the project is pointed to rather than shipped: the README directs readers to a Third-party Related Projects section for extensions, and offers a bookmarklet as the built-in alternative. That bookmarklet is a javascript: URL that rewrites github.com to github1s.com and back, and the README notes GitHub markdown does not allow js links, so it has to be copied into a bookmark manually.
Where GitHub1s is the wrong tool
The clearest limitation is that this is not an editing environment. The README routes all editing, container execution and pull request creation through Gitpod. If your task is to change a file and open a PR, the github1s.com view is a staging area, not the destination, and you are now depending on a second service with its own account and quota model.
The second limitation is the token boundary. Anything that requires a private repository means pasting a credential into a browser page. That is a reasonable trade for a developer reading their own company's code on a laptop, and a poor one on a shared or untrusted machine. The README does not describe token revocation handling or expiry behaviour, so if a token is pasted in the wrong place, the recovery path is GitHub's own token settings page, not anything GitHub1s provides.
The third is scope by construction. The project is a viewer for repositories hosted elsewhere. It does not host code, it does not replace a local checkout for running tests, and for a very large repository the experience is bounded by what the browser VS Code workbench and the file-fetching layer can hold. The README does not publish limits on repository size or file count, so treat any assumption about huge monorepos as unverified.
GitHub's own file viewer and the case for a local clone
The obvious comparison is GitHub's built-in code browsing. GitHub already renders file trees, syntax highlighting and blame, and it requires no domain change. The difference in approach is that GitHub1s loads an editor workbench rather than a document viewer. That means a persistent file explorer, editor tabs, a command palette, and the keyboard shortcuts a VS Code user already has in muscle memory. Whether that is better depends on how you read code. For following a single file top to bottom, GitHub's viewer is lighter. For jumping across a package, GitHub1s is closer to the tool you would use locally.
The other comparison is a local clone. A clone gives you the full toolchain, tests, language servers and no network dependency for reading. GitHub1s gives you none of that, and in exchange it gives you a URL. The honest framing is that GitHub1s occupies the gap between clicking through GitHub's web UI and running git clone, and that gap is real but narrow. If you already have the repository on disk, GitHub1s adds nothing.
Maintenance, releases and licence
The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive position, and it means forking GitHub1s for an internal code browser is legally uncomplicated. This is a description of the licence text, not legal advice; if you plan to redistribute a modified version, read the licence yourself.
On maintenance, the release cadence visible in the repository is active: v0.34.0 in August 2026, v0.34.1 in early September 2026, and v0.35.0 on 8 September 2026, with the last push to the default branch on 10 September 2026. The README lists three maintainers and names Sourcegraph as a sponsor. Release frequency is not a quality signal on its own, and nothing in the supplied material describes a support commitment, an SLA, or a deprecation policy for the hosted github1s.com instance. If you depend on the hosted domain, understand that you are depending on a service the README does not describe in operational terms. Self-hosting via npm run build is the path that removes that dependency, at the cost of running the front end yourself.
Editorial conclusion
Adopt GitHub1s if you need to skim a public repository with VS Code's file tree, search and syntax highlighting without cloning it, and treat the Gitpod button as the point where reading turns into editing. Do not adopt it as a replacement for a local checkout, as a code-hosting service, or as a way to keep private repository credentials in a server-side tool. Verify first that the OAuth token you generate is scoped as narrowly as GitHub allows, that the repository you care about is public, and that your browser extension or bookmarklet still matches the current github1s.com domain pattern.
Community notes