# Chatbox CE: code syncs in from a Pro repo, and the manifest says 0.0.1

> Chatbox Community Edition is an Electron desktop client for OpenAI, Claude, Gemini, and local Ollama models, shipped as installers for Windows, macOS, and Linux. The interesting parts are structural. A public tree fed by a private one, a manifest version of 0.0.1 beside v1.23.5 releases, and a packaging script that always targets the alpha update channel.

**chatboxai/chatbox** — Powerful AI Client

- Repository: https://github.com/chatboxai/chatbox
- Website: https://chatboxai.app?utm_medium=github
- Stars: 41,919 · Forks: 4,271
- Language: TypeScript
- License: GPL-3.0
- Published: 2026-08-17 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/chatboxai-chatbox

## The Community Edition tree is synced from a repo you cannot read

The README opens by naming the scope: this is the Chatbox Community Edition, open-sourced under the GPLv3 license, with a `LICENSE` file at the repository root. The next line is the one that shapes everything else, that code is regularly synced from the pro repo to this repo and vice versa. A linked issue is titled Chatbox is going open-source Again, which dates a previous closing.

Two consequences follow, and neither is visible from the file listing. First, feature completeness in the community tree is a vendor decision rather than a backlog you can read. There is no changelog in the top-level entries and no public pro repository to diff against, so when a capability is missing there is nothing to compare it to. Second, your pull request lives in a tree that is a sync target. A merge that the pro repo also touches can be rewritten by a later sync, and the README's contribution flow, fork from `main`, test, submit, gives you no way to detect that.

GPL-3.0 is the other half of the arrangement, and it governs what you may do with a modified build you distribute. The terms and the sync model are two separate things to examine, and only one of them sits in the file tree.

## package.json carries version 0.0.1 beside a v1.23.5 release

The root manifest identifies the package as `xyz.chatboxapp.ce` with `"productName": "xyz.chatboxapp.ce"`, and it is marked `"private": true`, so nothing is published to a registry from this manifest. It also says `"version": "0.0.1"`.

The release tags say something else. v1.23.2 shipped on 2026-09-10, v1.23.3 on 2026-09-16, and v1.23.5 on 2026-09-24, with the last push on 2026-09-24. A 0.0.1 in the manifest next to a 1.23.5 release means the version is not maintained in the file. Something in the build substitutes it, and the practical result is that you cannot learn the version of a Chatbox build from the source. You read it from the tag you downloaded, or from the application itself.

The tag sequence has its own wrinkle. There is no v1.23.4 between v1.23.3 and v1.23.5. If you pin a version in a managed rollout, expect gaps in the numbering, and do not write a script that assumes every patch between two versions exists.

## engines caps Node at one major, and the lockfile belongs to pnpm

Contributing means matching a narrow toolchain. The manifest states the requirement outright:

```json
"name": "xyz.chatboxapp.ce",
"version": "0.0.1",
"engines": {
  "node": ">=22.13.0 <23.0.0",
  "pnpm": ">=10.17.0"
},
"private": true,
```

That is an upper bound, not a floor. Node 22.13 through 22.x is accepted and Node 23 or 24 is not, so a machine with whatever Node the operating system installed will refuse to build until you switch. The `.node-version` file at the root is there to pin the same decision for version managers.

The package manager is equally specific. `pnpm-lock.yaml` and `pnpm-workspace.yaml` sit at the root, alongside a `packages/` directory, so this is a pnpm workspace and `npm install` will not reproduce the tree the project builds from. Two more hooks matter before you write any code. `postinstall` runs `node .erb/scripts/postinstall.cjs` on every install, and a top-level `patches/` directory is the pnpm mechanism for carrying patched dependencies. Skip install scripts and you lose both.

## UPDATE_CHANNEL=alpha is hardcoded into the packaging scripts

There are two families of release scripts in the manifest and they do not agree with each other. The local packaging pair pins the update channel:

```json
"package": "tsx ./.erb/scripts/clean.js && pnpm run build && cross-env UPDATE_CHANNEL=alpha electron-builder build --publish never",
"package:all": "tsx ./.erb/scripts/clean.js && pnpm run build && cross-env UPDATE_CHANNEL=alpha electron-builder build --publish never --win --mac --linux"
```

The three `electron:publish-*` scripts, one each for mac, linux, and win, run the build and then `electron-builder build --publish always` for their platform, with no `UPDATE_CHANNEL` set. So a build you make on your own machine is an alpha-channel artifact, and the scripts that actually upload artifacts do not set the channel at all. A fourth route exists as four shell wrappers, `release:web`, `release:mac`, `release:linux`, and `release:win`, each calling a `release-*.sh` script at the root.

One more asymmetry shows up in the web build. `build:web` sets `CHATBOX_BUILD_PLATFORM=web` and then runs `delete-sourcemaps`, while the three desktop builds do not. A stack trace from the browser version of Chatbox has no source map behind it, and the desktop builds keep theirs. That is a deliberate difference in what you get to debug.

## eslint, prettier, and biome each carry a config at the root

Three separate style tools are configured in one repository. `.eslintrc.js` and `.eslintignore` are the ESLint setup, `.prettierrc` is the Prettier setup, and `biome.json` is a third linter and formatter with its own rules. A change that satisfies one can fail another, and nothing in the contribution section of the README says which one wins.

The rest of the tooling is at least clearly separated. `vitest.config.ts` covers tests, `.storybook/` covers component work, `tsconfig.json` covers types, `tailwind.config.js` and `postcss.config.js` cover styles, and `i18next-parser.config.mjs` covers the translation keys behind the nine listed languages: English, Simplified and Traditional Chinese, Japanese, Korean, French, German, Russian, and Spanish. A parser config at the root means new interface strings arrive untranslated until someone runs the extraction step, which is why the README asks for help with translations.

The directory layout has the same problem in milder form. Both `doc/` and `docs/` exist at the root, and so do `script/` and `scripts/`. The README links to `./doc/README-CN.md`, `./doc/FAQ.md`, and `./doc/statics/snapshot_light.png`, so `doc/` is the tree in use and `docs/` is not explained anywhere in the file.

## The download table routes through the vendor site with a c= parameter

There are two ways in, and they are not the same. The quick start for end users says to download the appropriate installer from the GitHub releases page, install, launch, and then configure your AI provider in settings. The platform table higher up links somewhere else, to `https://chatboxai.app/?c=download-windows` and its siblings for mac Intel, mac aarch, and Linux. The `?c=` values are campaign parameters, so a scripted rollout should use the releases page rather than the table.

The build matrix is narrower than the app's reach suggests. System requirements list Windows 10 on x64, macOS 11 (Big Sur) on Intel or Apple Silicon, and Ubuntu 20.04 or later on x64. macOS is the only platform with both architectures built, so there is no Linux arm64 artifact for a Raspberry Pi or an ARM workstation, and no Windows build below version 10.

Mobile is distributed three ways: an App Store listing, a Google Play listing under the package id `xyz.chatboxapp.chatbox`, and a direct `.APK` link at `chatboxai.app/install?download=android_apk`. That id carries a different suffix from the desktop manifest name `xyz.chatboxapp.ce`, and a sideloaded APK skips the store's review and signing, which is a decision about where your updates come from.

## The Ollama list in the README is a snapshot, not the runtime list

The provider support list names OpenAI, Azure OpenAI, Claude, Google Gemini Pro, Ollama, and ChatGLM-6B. Under Ollama the README names specific local models: llama2, Mistral, Mixtral, codellama, vicuna, yi, and solar. Image generation is offered through Dall-E-3, and the rest of the feature list covers markdown, LaTeX, and syntax highlighting, a prompt library, message quoting, keyboard shortcuts, streaming replies, and a dark theme.

Those model names are the tell. The manifest carries a `generate:model-snapshot` script that runs `pnpm exec tsx scripts/generate-model-snapshot.ts`, so a list of available models is produced by a generator rather than typed by hand. Treat the Ollama list in the README as documentation of one moment. If you are pointing Chatbox at a local model that is not in that sentence, the client may still accept it, and the place to find out is the running app, not the README.

The same caution applies to the provider list itself. Adding a provider means changing code in a tree that is a sync target, so a provider that ships in the Pro edition may reach this repository on the vendor's schedule rather than on yours.

## Local data storage is a desktop claim, and team sharing is a server

One feature line says your data remains on your device, ensuring it never gets lost and maintains your privacy. That claim is scoped to the desktop application's own storage, and the same feature list contains something that sits outside that scope. Team Collaboration is described as sharing OpenAI API resources among your team, with its own document at `./team-sharing/README.md`.

A shared API resource is a server with other people pointed at it, so whatever the desktop claim covers, the team path needs its own answer about who can read a conversation. The README does not describe that, and it does not describe encryption at rest, export, or a sync mechanism. If the data you care about is sensitive, that is the first question to take to `./team-sharing/README.md` and then to the FAQ at `./doc/FAQ.md`, since those are the two documents the README points to.

The provider is a separate hop. Once you configure OpenAI, Claude, or Gemini in settings, your prompts and the model's replies travel to that provider. Local data storage describes where Chatbox keeps your history, not where a request goes while it is being answered.

## Conclusion

Chatbox Community Edition fits a developer who wants one desktop window over several providers, including a local Ollama model, and who is willing to treat the repository as a mirror rather than the source of truth. It does not fit a team that needs to know exactly which build it is running from the code, because the manifest carries 0.0.1 and the real number lives in a release tag. Check three things first. Whether your Node is inside the single major the manifest allows. Which channel the build you produce lands in, given that the packaging scripts set `UPDATE_CHANNEL=alpha`. And what the Pro-to-Community sync does to a patch you have open, since code is synced in both directions.

## FAQ

### What is the difference between ChatGPT and ChatBox ai?

Chatbox is a client, not a model. This repository holds the Community Edition, a GPL-3.0 desktop application for Windows, macOS, and Linux that you point at a provider such as OpenAI, Azure OpenAI, Claude, Google Gemini Pro, Ollama, or ChatGLM-6B, with your chat data kept on your own device.

### how to use chatbox ai

The quick start is four steps: download the installer for your platform from the releases page, install and launch Chatbox, configure your AI provider such as OpenAI or Claude in settings, and start chatting. Streaming replies and markdown rendering are available once a provider is set.

### how to install chatbox

Desktop builds are a Setup.exe for Windows, separate Intel and Apple Silicon builds for macOS, and an AppImage for supported Linux distributions. System requirements are Windows 10, macOS 11 (Big Sur), and Ubuntu 20.04 or later. iOS and Android versions are distributed through the App Store, Google Play, and a direct .APK link.

### Is ChatBox free?

The Community Edition in this repository is open-sourced under the GPLv3 license and downloaded from the releases page, with no per-seat or subscription element described for it. The project also maintains a Pro edition, and the README states that code is regularly synced between the two in both directions.

## Sources

- [Official documentation](https://chatboxai.app?utm_medium=github)
- [Official README](https://github.com/chatboxai/chatbox#readme)
- [Project repository](https://github.com/chatboxai/chatbox)
- [Release notes](https://github.com/chatboxai/chatbox/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chatboxai-chatbox