Fuji-Web, a sidepanel agent whose own test script does nothing

You paste your own key and it stays in the browser

The privacy claim is specific enough to check, which is unusual for a project of this size. You open the sidepanel from the extension icon, paste an OpenAI or Anthropic API key into the provided box, and that key is stored in your browser and not uploaded to a third party. All prompts, text and image alike, are sent directly to the API of the provider you selected, and the project states plainly that Fuji-Web does not attempt to collect any information from you. There is no account, no server component in the loop, and no telemetry described anywhere. What that does and does not cover is worth being precise about: the page you are on is still visible to whatever the model provider receives, which is why the extension asks you to navigate to a page first and then type the task.

Install is a zip, a developer-mode toggle, and Load unpacked

There is no package to install and no build required for the normal path. You go to the releases page, find the latest version, download the archive of the extension, and unzip it. Then in Chrome you open the extensions page, toggle developer mode on, click the button to load an unpacked extension, and select the unzipped folder. The documentation includes a warning you should not skip: you may need to refresh the page for the extension to work, which is the kind of note that only gets written after several people reported it. Once the page is refreshed you click the extension icon in the top right, open the sidepanel, and the task box is there. A demo video is linked from the top of the README, and the project also points at a separate blog post for benchmarks and a deeper technical overview.

Building needs pnpm installed globally and produces a `dist` folder

The from-source path is five steps and one of them is global. You need Node.js, developed on version 20 with the note that some lower versions should work. Then you clone, install pnpm globally with `npm install -g pnpm`, run `pnpm install`, and finally either `pnpm dev` to start the development server or `pnpm build` to build the extension. What you load afterward is the `dist` folder the build creates. The global install of the package manager is the step that trips people up, since a project-scoped dependency manager is otherwise the modern default, and it is the only place in the setup that touches anything outside the repository. Hot reloading is wired in: the development script builds the reload helper and then runs a reload server alongside the watch build in parallel.

The test script exits successfully without running anything

The package manifest is worth reading before you trust the codebase. The test script is `exit 0`, which means the suite passes unconditionally and there is no test being run when you invoke it. What the repository does enforce is narrower but real: the build script runs the TypeScript compiler in no-emit mode before the bundler, so a type error fails the build rather than shipping, and the lint script covers the source directory for TypeScript files only. Formatting is Prettier across the project, and commit messages go through a commit linter configured in its own file, wired in through Husky on prepare. So there is type safety, style consistency, and commit hygiene, and there is no behavioural test. If you are evaluating this as a dependency rather than a tool, that is the difference between knowing it compiles and knowing it works.

Firefox builds exist in the scripts but not in the documentation

The build matrix is wider than the install guide. There is a Firefox build script and a Firefox development script alongside the Chrome ones, each setting an environment flag before the bundler runs so the same source tree produces a browser-specific bundle. There is also a watch variant for each, and a separate library build that uses a different bundler configuration and copies a separate package manifest into its output directory, producing a second output tree alongside the extension. None of that appears in the installation instructions, which describe only the Chrome unpacked-extension flow. That is a reasonable omission for a project whose audience is mostly Chrome users, but it means the Firefox path is something you have to infer from the script names rather than read.

A library build exists, and the API for automation frameworks does not

The most interesting tension in the repository is between what the scripts can already do and what the roadmap says is still coming. There is a script that bundles the project as a library into its own output directory using a second bundler configuration, which is what you would need to consume Fuji-Web from another program. And yet the first item on the roadmap is exposing an API for integration with browser automation frameworks, naming Puppeteer, Playwright, and Selenium. So the packaging exists and the interface does not. The rest of the roadmap is broader in ambition: cross-tab workflows, more browsing behaviours such as selecting from a dropdown and extracting content from a whole page, saving workflows, sharing workflows and instructions with other people, and a collaborative knowledge base in the spirit of a wiki to improve performance.

The newest tag is from September 2024 while the branch has moved since

Version signals point in two directions here. The three most recent tags are all from 2024: a patch release in July, a minor release in early September, and another patch in mid-September. The project manifest declares version 2.2.0, which is the minor release rather than the latest patch. Meanwhile the branch was pushed on 2026-09-12, so there is close to two years of commits after the last tagged release and the default branch is not archived. If you install from a release you get 2024 code; if you clone the branch you get something two years newer with none of the release notes to tell you what changed. That gap is the main practical risk in depending on this project, and the fix is to check the commit history yourself rather than trusting the version number in the manifest.

Grounding leans on accessible names, and the UI started from another extension

Two things explain how the agent finds things on a page. One is a dependency on a library that computes accessible names, which is the accessibility-tree label for an element rather than a pixel coordinate or a CSS selector. That is the right primitive for an agent that has to explain what it clicked. The other is that the image annotation method was inspired by a published paper on visual prompting, credited in the README. The provenance is unusually well documented for a project this size: the idea of a tool living in the browser sidepanel came from another company's extension, some of whose interface code was reused, the extension scaffolding came from a public boilerplate project, and even the logo is taken from an existing emoji design set. The single environment variable in the example file is a debug toggle.

Editorial conclusion

Fuji-Web fits someone who wants to hand a repetitive browser task to a model without standing up a server or giving a third party their key, and who is willing to load an unpacked extension. The privacy story is simple and checkable: the key stays in the browser and prompts go straight to the provider you chose. It is a poor fit if you need a tested codebase, since the test script exits successfully without running anything, or if you need the planned automation-framework integration, which is still on the roadmap rather than shipped. Before you rely on it, read the troubleshooting guide, and note that the newest tag is from 2024 even though the branch has moved since.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. normal-computing/fuji-web on GitHub
4. README
5. Releases