# Browser-BC: a default key shipped inside the extension, no Node needed next to a pnpm build step, and a paper to cite with no licence to grant > Journey Forge Local is a local-only recorder for browser tasks. You record what you do, each site accumulates folders of capabilities, and a background pipeline distils each capability folder into a skill file that installs itself into your Claude skills directory. It is described as the productised companion to a paper on behaviour cloning through skill distillation, it needs your own model key, and it says plainly that it is not a benchmark. **Einsia/Browser-BC** — Agent behavior clone for browser using, targeting general GUI using and distributed trajectory collecting. - Repository: https://github.com/Einsia/Browser-BC - Stars: 557 · Forks: 57 - Language: TypeScript - License: not declared - Published: 2026-09-17 · Updated: 2026-09-17 · Language: en - Canonical page: https://hysenlabs.com/projects/einsia-browser-bc ## A constant key ships in the extension and is seeded into the server The quick start configures the server like this: ```bash cp config.example.env .env.local # then set SF_LLM_KEY=sk-ant-... ./scripts/start.sh # or: python entry/main.py (native window) ``` and the paragraph underneath says the panel is at a loopback address, and that the server seeds a default key which the extension ships with, so that it connects automatically. So the value of that key is a literal string in the source of a browser extension that anyone can download and read, and the server accepts it without configuration. The security of the ingestion endpoint therefore rests entirely on the bind address being loopback, not on the credential. That is a defensible design for a single-user local tool and the page is upfront about it, but it means the tool cannot be exposed to a second machine, a container port, or a tunnel without the first thing anyone does being changing the key. Nothing in the quick start says that. ## No Node needed, immediately above a step that builds with pnpm The opening paragraph says the runtime is pure Python with no Node needed, and the layout table attributes that to the control panel being served as a pre-built page and the harness being pure Python. Two steps later, the extension build is: ```bash cd extension && pnpm install && pnpm build ``` which is a Node toolchain, a package manager, and a bundler. Then the reader is sent to the browser's extension page, turns on developer mode, and loads an unpacked build. So the claim holds for everything after the build and not for the build itself, and the distinction is not drawn anywhere. That matters for a specific reader: someone who arrives without Node installed and reads the first paragraph will conclude there is nothing to install, then hit the second step. The distinction the page should be drawing is between what ships as compiled output and what you have to produce, and there is a second instance of the same split. The panel's built output is committed to the repository and served as-is, while the extension's built output is something you generate. ## Two environment variable prefixes for one product The product has three names and two of them leak into the configuration surface. The repository is called for browser behaviour cloning, the product is called Journey Forge Local, and every release tag carries the product name rather than the repository name, with three of them published inside a single day. The configuration is worse. The model key and the model endpoint use one two-letter prefix, while the flag that switches the desktop window onto a native toolkit uses a different three-letter prefix with a matching initial. So a user grepping their own configuration file for the product's initials finds one variable and not the other. Neither prefix matches the repository name either. None of this breaks anything at runtime, since both variables are read by name, but it is the kind of inconsistency that costs an afternoon when you are trying to script the setup across two machines. ## Four runtime dependencies, all floors, and no declared Python version The requirements file is short and heavily commented. A web framework and an async server, a TOML reader with a comment explaining that the standard library only carries one from a certain Python version onward, and then a commented-out optional dependency with a note that it pulls a platform-specific bridge on macOS and is slow and fragile to install, together with the command that installs it and the variable that enables it. The comments are the best part: someone worked out why each line is there. What is missing is a ceiling on any of them. All three active lines are floors with no upper limit, and the repository has no project descriptor declaring a minimum Python version, so the supported interpreter is inferred from a comment about when the standard library gained a module. For a single-user local tool that is a defensible level of rigour, and it is a different level from the rest of the page, which pins a model name and a port and a directory layout with great precision. ## Skills grant instructions, not tools, and only one target is automated The most useful sentence on the page is a limitation. A skill file is injected instructions; to execute its steps in a browser you have to configure a browser automation server separately. So the output of the whole pipeline is text that tells an assistant what to do, and something else has to make it happen. The panel automates that configuration for one target. For the coding tool, the skill is installed automatically under the user's skills root and the page says it is already there. For the desktop application, you download an archive from the panel and upload it through a settings dialog, and the page links a separate setup document. Browser execution is then marked optional in the quick start, which is a strange thing to make optional when executing in a browser is the entire purpose of a browser behaviour clone. The design rule is right and the ergonomics are uneven between the two targets. ## A paper to cite, and no licence to grant The page asks you to cite a specific arXiv preprint, gives the full author list, and supplies a BibTeX entry in the correct article form with the preprint identifier in the journal field. That is careful work. The repository, though, has no licence file: the top level is a CI directory for one host, a CI file for another, a gitignore, the readme, nine directories, one example configuration file, one requirements file, and a scripts directory. The licence is recorded as unknown. So the project asks for citation credit and grants no permission to use, modify, or redistribute the code, and the readme's closing instruction to cite applies to the ideas rather than to the artefact. The page also carries two CI configurations for two different hosting services, which is the one piece of genuine duplication here: everything else is either a deliberate single choice or a documented consequence of it. ## The example bucket taxonomy names a login-with-credentials capability Each site becomes a folder of capability buckets, and the page's own example is a folder with a login capability and a signup capability named beside each other, on a well-known site. That is the taxonomy the classifier produces, illustrated with the most sensitive case available rather than a neutral one. The pipeline runs unattended in the background: it takes a recording, splits it into segments, classifies each one into a capability, pools segments of the same capability into a bucket, and distils the bucket into a skill file plus a guide, then installs it. State lives under a data directory that is ignored by git, and each installed capability gets a metadata file and an evidence file. So whatever you typed while recording, including a password field, is written to plain text in a directory with no backup path described, and the resulting skill file lands where your assistant will read it as instructions on every future session. Nothing here is a flaw in the tool's design; it is a consequence of the design worth knowing before the first recording. ## Conclusion This is a neat piece of personal tooling with a clear design rule, which is that skills are text and tools are not, and the page refuses to blur them. That rule is worth more than most of the features. Two things to check before you record anything you care about. The authentication story rests on a loopback bind address rather than on the key, since the key is a constant in the shipped extension, so do not run the server on a shared machine or behind any kind of tunnel. And read the bucket taxonomy before your first recording, because capability names are generated from what you did and whatever you typed while doing it ends up written to disk as plain text in an ignored directory and installed as an instruction file. ## FAQ ### What does Browser-BC do with a recorded browser task? The recording is uploaded to a local server in three stages, then a background pipeline atomizes it into segments, classifies each segment into a capability, pools segments of the same capability into one bucket per site, distils each bucket into a skill file and a trace guide, and installs the result. A skill appears within about one to three minutes with auto-distillation on. ### How do I install a Browser-BC skill into my assistant? For the coding tool it goes automatically under the Claude skills root as a domain-and-capability folder containing the skill file. For the desktop application you download an archive from the panel and upload it under Settings, then Skills, following a separate setup document. ### What does Browser-BC need from an LLM provider? Your own key, set in a local configuration file. The distiller speaks the Anthropic Messages API natively and defaults to a named Opus model; pointing the base URL variable at an OpenAI-compatible gateway uses that path instead. Data stays on the machine apart from those distillation calls. ### Can Browser-BC actually drive a browser? Not on its own. A skill file is injected instructions, not a tool, so executing those steps requires configuring a browser automation server separately. The panel automates that setup for the desktop application, and the page marks browser execution as an optional step. ## Sources - [Einsia/Browser-BC on GitHub](https://github.com/Einsia/Browser-BC) - [Issues](https://github.com/Einsia/Browser-BC/issues) - [README](https://github.com/Einsia/Browser-BC/blob/master/README.md) - [Releases](https://github.com/Einsia/Browser-BC/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/einsia-browser-bc