Version 26.9 changes GitHub across desktop and mobile browsers
Refined GitHub 26.9 is a browser extension for Chrome and other Chromium browsers, Firefox including Android, and Safari on macOS, iOS, and iPadOS. It changes the GitHub website in place. Repository headers gain context, pull-request pages get faster actions, comment boxes behave better, notification controls become easier to reach, and small fixes cover gaps in GitHub's own interface. GitHub Enterprise is supported after the user grants access to the additional host.
The extension makes the most sense for people who can name several GitHub irritations before reading the feature list. A shortcut to copy a permalink, a filter for unresolved review comments, or a visible link from a workflow run back to its pull request saves little once and plenty after months. Users who visit GitHub occasionally will gain less, while also having to learn why a page differs from screenshots in GitHub's documentation.
The 2.8 MB source tree hides a much larger contributor setup
Our checkout was only 2.8 MB with 565 files and about 28,385 lines of source. Installing it added 678 npm packages and expanded the environment to 383 MB. That footprint belongs to contributors, not people installing the packaged browser extension. The source combines TypeScript, Svelte checks, Rollup bundling, Vitest, formatting tools, and two linters. Its 8 CI workflow files and tests directory show that interface tweaks receive more engineering structure than a typical userscript collection.
Commit 53186f2 declares Node 24 or newer and npm 12.0.2. Our supplied sandbox used Node 22 and still completed installation and build, but contributors should follow the declared engine rather than infer support from that one result. There is no Dockerfile, which is unsurprising for an extension. The user-facing route is a store package, while source work needs the JavaScript toolchain and a browser profile for interactive checks.
What happened when we ran it
Our sandbox installed 678 packages in 24 seconds and occupied 383 MB on disk. The build succeeded in 19 seconds. We ran commit 53186f2 in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. Npm audit reported 0 known vulnerabilities across the installed dependency tree, which is a clean result for the measured snapshot rather than a guarantee about later releases.
The full test command exited 1 after 45 seconds. Vitest reported 564 passed, 0 failed, and 28 skipped out of 592, and Svelte's checker found 0 errors and 0 warnings. The failing step was ESLint: source/features/quick-comment-edit.tsx at line 38:6 passed one selector string where the project's byo/selectors-array rule requires an array with a comment for each selector. The log shows a style-policy failure, not a failed behavior assertion.
One ESLint error blocks a suite with 564 passing checks
The distinction matters if you are judging commit 53186f2. All 564 executed Vitest checks passed, yet the repository's test script intentionally runs tests, linters, and build checks together. One policy violation therefore makes the command fail. That is stricter than projects that report green after unit tests alone. It also means a contributor cannot call the measured commit clean until the selector expression satisfies the rule and the combined command is rerun.
For an extension user, the more relevant checks happen in the browser. Refined GitHub injects a content script at document start on GitHub and Gist, stores preferences, adds context-menu entries, and calls the GitHub API. The manifest asks for those host permissions, plus optional access for other hosts such as an Enterprise domain. Security teams should review that scope as they would any extension that can read and change pages containing private source discussions.
GitHub changes can hide a control before version 26.9 is hotfixed
Issue 10027 reports that version 26.9's clean-repo-sidebar feature removed the About heading and settings control on repositories owned by the viewer. Maintainers labeled the feature "disabled via hotfix," which is a sensible response and a reminder of the maintenance model. Refined GitHub depends on GitHub's live markup. A feature can be correct on Monday and collide with a site rollout on Tuesday.
Browser parity has similar edges. Release 26.9 disabled sidebar-focus-file on Firefox because it was unsupported. Issue 6336 documents linkify-code failing in Safari's newer file viewer. Neither report makes the extension broadly unreliable. They do make it a poor fit for teams that promise the same assisted workflow on every browser or encode extension controls into formal operating instructions.
The September 2026 release and 72 open items show an active feedback loop
GitHub showed 32,034 stars and 72 combined open issues and pull requests when fetched. The repository was pushed on September 2, 2026, and release 26.9 arrived the same day. Issues 10027 and 10028 were also opened that day, with a related repair pull request already present for the missing repository edit control. Push, release, issue, and repair activity together point to an actively maintained project facing an actively changing host site.
The project admits that it is opinionated and sets a high bar for new features. Most JavaScript features can be disabled; CSS changes require custom overrides. That is a fair bargain for individual developers who want the maintainer's choices and can turn off a misfit. A company seeking one approved, frozen GitHub interface should use native GitHub, the official CLI, or a much narrower extension instead.