px0: A Read-Only Browser IDE for Reviewing Agent-Generated Code
px0 is a fast, lightweight, read-only IDE designed for instant code navigation and review in your browser. Booting in under 1 ms and using ~20 MB of RAM, it turns your browser into a zero-latency inspection console with symbol-level navigation, deep search, and syntax highlighting across massive codebases.
At a glance
- What is it?
- px0 is a single Go binary that serves a read-only code browser on localhost, with fuzzy file search, regex project scan, Chroma syntax highlighting, optional LSP, and git diff badges. It is aimed at reviewing code you did not type, and its own README is the main place to look for what it does not do.
- Who is it for?
- Adopt px0 if your workflow already generates code in a terminal and you want to inspect it without opening an editor: install it with curl -fsSL https://px0.ai/install.sh | bash, or build from source with make build if you prefer to audit the binary, then run it in the repository you are reviewing. Do not adopt it if you need to edit, refactor, or run tests from the same window, or if you rely on a language server that is not in the detection list, since px0 ships none.
- 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 JavaScript, 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 problem px0 addresses: review without an editor
The README makes an argument rather than a feature list. Code generation is increasingly driven from terminals by agents and CLI tools, so the developer's job moves toward inspection: reading diffs, tracing a symbol to its definition, scanning a project for a pattern. A desktop IDE is a poor fit for that job because it carries editing machinery you are not using. px0's answer is a read-only browser interface served from a single static binary. The target user is someone who already has a terminal open, has just generated or pulled a change, and wants to look at it without paying the startup and memory cost of a full editor. The README claims boot in under 1 ms and roughly 20 MB of RAM. Those are the project's own numbers; nothing in the repository description explains how they were measured, and the README does not give a benchmark methodology. Treat them as design targets rather than verified figures.
One Go binary, an embedded frontend, and a virtual DOM
The distribution model is the most concrete thing about px0. It is a single static binary with HTML, CSS, and JS embedded inside it, with no npm, no Node, and no CGO required to build. The README states there are zero runtime dependencies and no cloud phone-homes. Rendering is handled by a virtual DOM: opening a 400,000-line file costs the same as a 10-line file because only visible lines render in the browser. That is the mechanism behind the large-file claim, and it is a real architectural choice rather than a marketing line. Syntax highlighting comes from Chroma, with native tokenization for around 280 languages, and the binary ships 14 themes including Tokyo Night as the default. Search is split into three modes with distinct keybindings: fuzzy file search on Cmd/Ctrl+P, document symbols on Cmd/Ctrl+Shift+O, and a full project regex scan on Cmd/Ctrl+Shift+F. The outline and regex paths are built in and work with no external tooling at all, which matters for the fallback story below.
LSP is detected, never bundled
px0 does not ship a language server. It looks for one on PATH and in a list of usual install folders: ~/go/bin, ~/.cargo/bin, ~/.local/bin, npm's global folder, and Homebrew's folders on macOS. The README gives a table mapping languages to servers and to install commands, for example go install golang.org/x/tools/gopls@latest for Go, rustup component add rust-analyzer for Rust, and npm install -g typescript-language-server typescript for TypeScript. Where a language has several candidates, the first found in the listed order wins; Python is the clearest case, with pyright, pylsp, and ruff all detected, but the README notes that ruff gives no call trails. Servers are spawned lazily on the first request for that file type and shut down on exit. Detection can be turned off entirely with px0 -no-lsp. This is a sensible design for a tool that wants to stay a single binary, but it pushes the setup burden onto you, and semantic Go-to-Definition on F12, hover docs, and cross-references simply do not exist until a server is present.
Git awareness and diff viewing
Inside a git repository, the file tree badges each file by status: M for modified, A for added, D for deleted, U for untracked, R for renamed. Changed files are coloured green for additions and red for deletions or modifications, and folders containing changes are marked. A changed only filter hides clean files. For a modified file, Split and Unified buttons appear next to the tab bar, or Cmd/Ctrl+D opens the diff against HEAD, side by side by default, with old and new line numbers in both layouts. The whole feature is disabled with -no-git or when git is not present. This is the part of px0 that most directly serves the review use case the README describes, and it is read-only in the same way as everything else: you can look at a diff, not stage or commit from it. Anyone expecting a staging area or a commit UI will not find one here.
Installing and running px0
On macOS, Linux, and BSD, the quick path is curl -fsSL https://px0.ai/install.sh | bash, which installs or upgrades to the latest release. Piping a remote script into a shell is a decision you should make deliberately; the alternative is building from source. That requires Go 1.24 or newer, and the README gives the sequence: git clone https://github.com/px0-ai/px0.git, cd px0, make build, then sudo install px0 /usr/local/bin/. Cross-compilation for all 15 supported OS and architecture combinations is done with make dist or ./build.sh. The flags named in the README are -no-lsp and -no-git, both of which disable detection or integration you might not want. The CLI is described as following the Ape design spec, with a 256-color palette, Unix pipe detection, and quiet automation modes, which suggests it is meant to behave well when scripted. Beyond those flags, the README does not document a configuration file, a port setting, or a rollback path.
Where px0 is the wrong tool
The read-only constraint is the whole product, and it is also the sharpest limitation. If your task is to change code rather than inspect it, px0 has nothing to offer, and the README does not present it as an editing environment. The LSP story has a second edge: because px0 detects servers rather than shipping them, semantic navigation is only as good as your local setup, and a language outside the detection table gets regex outlines only. The README is explicit that the built-in fallback is regex-based, which will not resolve overloads or follow imports the way a real server does. There is also a documentation gap worth naming. The README covers installation, themes, LSP detection, and git badges, but it does not document uninstall, upgrade rollback, or how the binary is configured beyond the flags it lists. For a tool you install with a curl pipe, that is a real thing to weigh before putting it on a shared machine.
How px0 differs from a full IDE or a hosted code browser
The obvious comparison is a desktop IDE such as VS Code or a JetBrains product, and the difference is not just weight. Those tools own the edit, the debugger, the terminal, and the extension ecosystem; px0 owns none of them and instead optimizes one path, opening a repository in a browser tab and finding things in it quickly. The other comparison is a hosted code browser like GitHub's file view or Sourcegraph. Those run remotely against a server or a hosted index and bring search across many repositories, at the cost of sending your code to a service. px0 runs as a local binary and the README states there are no cloud phone-homes, so the code stays on your machine. That is the trade: you give up cross-repository search and collaboration features, and in return you get a local, dependency-free viewer with git diff and optional LSP. The choice is about where your code lives and how much tooling you are willing to install, not about which one has more features.
Maintenance, licence, and what to verify before adopting
The repository is not archived, the default branch is master, and the last push was on 2026-09-14, the same day as the v0.1.2 release. The release history is short and recent: v0.1.0 on 2026-09-13, v0.1.1 on 2026-09-13, and v0.1.2 on 2026-09-14. That cadence suggests early, active work, but three releases in two days is not a track record, and the version numbers themselves say this is pre-1.0 software. The licence is MIT, which permits commercial use and modification with the usual requirement to preserve the copyright and licence notice; that is a description of the licence text, not legal advice, and if you redistribute px0 inside a product you should read the full MIT terms yourself. The upgrade cost is low by design: a single binary, no runtime dependencies, and an install script that upgrades to the latest release. The risk is the opposite of lock-in: with no configuration file documented and no rollback instructions in the README, a bad upgrade is something you resolve by reinstalling a known version manually. Before adopting, check that your language server is on PATH or in one of the folders the README names, and confirm that the read-only boundary matches how your team actually works.
Editorial conclusion
Adopt px0 if your workflow already generates code in a terminal and you want to inspect it without opening an editor: install it with curl -fsSL https://px0.ai/install.sh | bash, or build from source with make build if you prefer to audit the binary, then run it in the repository you are reviewing. Do not adopt it if you need to edit, refactor, or run tests from the same window, or if you rely on a language server that is not in the detection list, since px0 ships none. Verify first that your language server is on PATH or in one of the folders the README names, and that you are comfortable with a project whose README does not document rollback, uninstall, or configuration beyond the CLI flags it lists.
Community notes