claude-nexus: a chat extension whose prompt library reads another extension's format

Folders are drag and drop and the structure lives in the browser

The first feature is the plain one: move conversations into folders by dragging them, then rename, delete or reorganise at any time. The storage note is what matters for a chat tool, because the folder structure is saved locally and survives across sessions rather than being tied to an account.

The second feature is a timeline. Visual nodes represent the structure of a conversation so you can see its shape at a glance, the panel is fixed to the right, clicking a node jumps to that message and hovering previews it. That is a navigation aid for the case where a long thread has scrolled away from the part you need.

The third is a floating ball you can drag anywhere, opening panels of common actions. One of those actions is chat width, adjustable between 38 and 90rem with a default of 48rem, which is the kind of setting that usually lives in a browser zoom menu otherwise. Both the timeline and the floating ball are overlays on a page the extension does not own, so positioning and event handling are the parts to watch in a release.

The prompt library speaks another extension's format

The prompt library stores, searches, edits and inserts snippets directly into the chat input toolbar, and it does its import and export through a named format rather than its own.

Import takes a `.json` file exported by gemini-voyager, skips duplicates and shows the result, so a bad import reports what happened instead of failing silently. Export downloads a file named `claude-nexus-prompts-{YYYY-MM-DD}.json`, and the format identifier is fixed as `gemini-voyager.prompts.v1`. The name in the identifier is not a copy-paste slip: the credits name gemini-voyager as the project this one is inspired by, an all-in-one enhancement suite for Google Gemini.

So two extensions for two different assistants share one prompt format, and the version string is what keeps them compatible. That is a deliberate interop choice, and it is why the v0.2.0 release is titled for gemini-voyager prompt interop rather than for a feature.

Two script names do exactly the same build

The manifest defines a Chrome path, a Firefox path, and duplicates of each under a shorter name. `build` and `build:chrome` both run `vite build --config vite.config.chrome.ts`, and `dev` and `dev:chrome` both run `nodemon --config nodemon.chrome.json`.

The Firefox targets are the interesting half. `build:firefox` and `dev:firefox` have their own Vite configs and their own nodemon configs, and the repository carries `manifest.json` alongside `manifest.dev.json` plus three Vite config files, a shared base and one per browser. So the code has a Firefox path even though the README documents only Chrome, the Chrome Web Store listing, and Chrome Manifest V3.

Manual installation names the output folder to load: build with `yarn build:chrome`, then open `chrome://extensions`, enable Developer mode, click Load unpacked and select `dist_chrome/`.

ESLint 9 is installed next to a .eslintrc filename

The repository root holds a `.eslintrc` file, the pre-v9 configuration filename, while the development dependencies install `eslint` at ^9.32.0. ESLint 9 looks for a flat config by default, so the config file in the tree is the format the previous major expected.

The plugin list is modern and broad: typescript-eslint at 7.x for the parser and plugin, eslint-config-prettier, and plugins for imports, JSX accessibility, React and React hooks. So the linting intent is clear and the loading mechanism is the thing to verify before you run it.

The rest of the toolchain is unremarkable in the good way. Vite with `@crxjs/vite-plugin` and the React plugin, Tailwind 4 through its Vite plugin, TypeScript, and a hand-written `custom-vite-plugins.ts` at the root. One inconsistency is worth naming: the README describes the build as Vite plus vite-web-extension, while the manifest lists the CRXJS plugin.

The development loop is three manual steps after every build

Development mode is a single command with auto-rebuild:

# Start development mode with auto-rebuild
yarn dev:chrome

# After each build:
# 1. Open chrome://extensions
# 2. Click the refresh button on claude-nexus
# 3. Refresh the claude.ai page

Those three steps are the loop. Reload the extension, then reload the page it injects into, because a content script does not pick up a new bundle until the tab is refreshed.

Dependencies come from yarn, with a `yarn.lock` at the root and no npm or pnpm lockfile, and the install step is `yarn install`. Node version is pinned in a `.nvmrc`, and there is a `.vscode/` directory, so the project expects a specific editor setup as much as a specific runtime.

Documentation is VitePress, with `docs:dev`, `docs:build` and `docs:preview` scripts over a `docs/` directory, separate from the extension bundle itself.

v1.4.1 fixed a prompt injection, and a month of commits sit past it

The release titles carry the substance. v1.4.1, published 2026-07-04, is titled for folder and prompt injection fixes. v0.3.0 from 2026-03-22 is UI polish, bug fixes and Traditional Chinese, and v0.2.0 from 2026-03-11 is the gemini-voyager prompt interop.

A prompt-injection fix in a tool that reads your conversation history is worth noting for what it implies about the extension's attack surface: it parses text that came from a model, and that text can carry instructions. Treat the fix as a signal that the parsing path matters.

The version in `package.json` reads 1.4.1, matching the newest tag, and the last push is dated 2026-08-03, so the branch carries about a month of commits beyond the published extension. The store listing is what most people actually run, so the gap between the two is the gap between what you can read in the repository and what you get from the store.

Bilingual support is two libraries and a popup entry

The language switch is minimal by design. You open the extension popup from the browser toolbar and choose between Chinese and English, and the implementation is `i18next` with `react-i18next` in the runtime dependencies.

The rest of the runtime dependency list explains the rest of the extension: React and React DOM at 19.x for the panel UI, `lucide-react` for icons, and `webextension-polyfill` so the same code can call the extension APIs through one interface rather than checking for `chrome` at every call site. That last dependency is what makes the Firefox targets in the scripts plausible.

Together with chat export to Markdown or JSON from the toolbar, the feature set is small and legible: organise, navigate, resize, store prompts, export, translate. Nothing here proxies or rewrites a request, which is also the reason nothing here needs a server.

Editorial conclusion

claude-nexus fits someone with a long claude.ai history who wants folders, a way back into old messages, and their prompt snippets in one place rather than in a notes app. It does not fit a team that needs audited data handling or a Firefox release path, since the documentation covers Chrome only and the conversation data it reorganises is the vendor's. Before you install it, read the release notes for the prompt-injection fix, decide whether locally stored folders and exported chats meet your own retention rules, and remember that the newest tag is v1.4.1 while the repository has moved on since 2026-07-04.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Qiuner/claude-nexus on GitHub
4. README
5. Releases