DiscordBotClient puts a bot token in a desktop window it tells you not to use
A patched version of discord, with bot login & Vencord support
At a glance
- What is it?
- A TypeScript and Electron rebuild of the Discord desktop application whose first startup screen takes a bot account instead of a user token. Sixteen Discord builds are tabulated, one client release receives fixes, and the four published binaries are unsigned.
- Who is it for?
- Discord's terms discourage third party clients and DiscordBotClient says so on its own front page, so running it means handing a bot token to an unsigned build and accepting that a bad outcome on that account has no appeal. It earns its place only for the piece it adds to the official API: a real client window with Vencord built in.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 4, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The bot token goes in through the application's own login window
DiscordBotClient is not a bot library. It is the Discord desktop application rebuilt in TypeScript and packaged with Electron, and the patch it carries is a login form on first startup that accepts a bot account and drops it into the normal client shell. The stated goal is narrow: use your bot like any other user account, except for Friends and Groups. Groups are missing by design, so a bot account in this client never gets the surfaces that depend on being a household of users.
That framing carries a warning the project prints on its own front page: third party clients are discouraged and against the Discord TOS. The same page claims the application only uses the official Discord API and doesn't send data to third parties, and adds that it is not an official product by Discord Inc. The code is GPL-3.0, the default branch is `electron-v3`, and the repository counts 1477 stars, 110 forks and 29 open issues.
Login happens in the UI. There is no config file to edit and no flag to pass. One gateway intent has to be switched on before anything works, `MessageContent`; every other intent is optional, and the document tells you to enable all of them when you want the member list and each member's status.
The build script runs its own dependency steps a second time
Building from source is six lines, and needs NodeJS v24 or higher plus git:
git clone https://github.com/aiko-chan-ai/DiscordBotClient.git
cd DiscordBotClient
npm run requirement
npm run vencord
npm run build:ts
npm run buildThe script graph underneath those lines does more work than the recipe asks for. `requirement` is `npm install && tsx scripts/vencordClone.ts && tsx scripts/discohookClone.ts`, so the name promises a prerequisite check and delivers an install plus two repository clones. `build` is `npm run build:deps && npm run build:ts && npm run build:bin`, and `build:deps` is `npm run vencord && npm run discohook`. Following the document in order therefore compiles the Vencord patch twice, once on its own line and once inside `build`, and runs the TypeScript compile twice for the same reason.
Two other details sit oddly beside the stated floor. The document requires NodeJS v24 or higher, while the type definitions in package.json ask for `@types/node` at ^26.1.1. The package entry point is `build/index.js`, the compiler output directory, yet the executable the build produces is named `DiscordBotClient` or `DiscordBotClient.exe` and lands in `dist`.
Packing is where electron-builder takes over. `build:bin` is the bare `electron-builder`, and three sibling scripts narrow it per platform: `mac` passes `-m`, `win` passes `-w` and `linux` passes `-l`. Nothing in the recipe picks one, so the last step follows whatever the host operating system reports.
npm test compiles the project and opens a window
The script named `test` is `npm run build:ts && npm run start`, and `start` is `electron .`. Running it type checks the tree and then launches the graphical application; nothing is asserted and no test runner appears anywhere in the manifest. `test:typescript` is the honest one, a bare `tsc --noEmit`. The two wrappers `test:vencord` and `test:discohook` prepend a dependency build and then call the same launching script, so all three names reach the same place.
The top level of the tree holds sixteen entries and none of them is a test directory: an `assets` folder, a `docs` folder, a `scripts` folder, a `src` folder, `dev-app-update.yml`, `package-lock.json`, `tsconfig.json`, both `LICENSE` and the readme, and two lint configurations that coexist without explanation, the legacy `.eslintrc.json` and the flat `eslint.config.mjs`. The lint script still passes the old style switch, `eslint src --ext .ts`.
The visible type dependencies describe a local HTTP layer: `@types/express`, `@types/morgan`, `@types/multer` for a multipart handler, `@types/http-proxy`, `@types/ini`, `@types/jsdom`, `@types/js-beautify` and `@types/probe-image-size`. A proxied HTTP surface is exactly what the claim about the official API and no third parties would have to explain, and no part of the document explains it.
Two repositories get cloned and one of them is never named
The feature list ends with Vencord built in, and Vencord is indeed a build input: `npm run vencord` runs `tsx scripts/vencordBuild.ts` after `scripts/vencordClone.ts` has fetched the repository. The same pattern applies to a second project that the prose never mentions by name. `requirement` clones both `vencordClone.ts` and `discohookClone.ts`, `build:deps` builds both with `tsx scripts/discohookBuild.ts`, and `test:discohook` exists for it. So a machine building from source pulls two external repositories, while the feature list advertises one.
Maintenance of the Discord core is a third script, `core:update`, running `tsx scripts/update.ts`, and the root carries `dev-app-update.yml` for the updater that electron-builder reads. The table of contents promises a section on how to update to the latest Discord version, and the build section opens with a struck through line reading UPDATES MUST BE INSTALLED MANUALLY. Its footnote marker is reused further down on the Stable 491153 row of the compatibility table, so one marker carries two unrelated statements.
Fifteen Discord builds, and a Latest row full of question marks
The compatibility table is the most useful page in the document and also the most confused. It carries fifteen data rows running from Stable 204762 at client v2.4.2 up to a row labelled Latest whose Discord build, hash and Vencord column are all question marks and whose client version reads v3.9.?. Its release status cell holds a struck through Beta with nothing written after it, and its app status is the symbol the legend defines as basic functionality still under development.
Twelve of the fifteen rows are marked EOL. One, v3.9.1, is marked Deprecated, and only v3.9.3 against Stable 589596 is marked Latest. The labels are not ordered by age: v3.9.2 is end of life while the older v3.9.1 is merely deprecated. Stable 510733 appears twice, once for v3.9.1 and once for v3.9.0, sharing the hash 2fcef2a and Vencord v1.14.5. The Vencord column spans v1.2.8 up to v1.15.0 across the whole history.
The prose above the table settles the rest: only the latest version of the application is supported, other versions will not receive bug fixes, and rows that were removed were unstable and did not work properly. So the fifteen row table is a wall of dead ends around one supported line. That line is v3.9.3, published on 2026-08-08, while the branch has been pushed on 2026-10-01.
The feature list subtracts as much as it adds
Reading the feature list against its footnotes gives the honest shape of the client. Guild creation is struck through, and the marker points at Discord's own change log for deprecating guild creation by apps, so the platform removed the capability the client would have exposed. Voice is listed with everything related to streams excluded. Direct messages are marked as implemented with restrictions on the client, which is not the same as unrestricted, and Friends and Groups are absent from the start.
Nitro is listed but reduced in three named ways: stickers cannot be used everywhere, files larger than 10 MB cannot be sent, and avatar decorations cannot be set. Those are subscriber features that a bot account reaches only partially, which makes sense given the account type and quietly caps what the client is good for.
What remains is a working set: sharding, lazy loading of guilds, guild and channel management, message send and history with embeds, reactions, components and poll creation, and a bot account driven through the same gateway intents any library would use. Message components are marked as version 2, and the marker on that line is the same one attached to the v3.9.0 row of the compatibility table, so a feature footnote and a build footnote share a number.
Four published binaries and not one of them is signed
Windows can be installed through the package manager:
winget install aiko-chan-ai.DiscordBotClientThe other three platforms are prebuilt downloads only, and the table of them names four artifacts: `DiscordBotClient-win-x64.exe`, `DiscordBotClient-linux-x86_64.AppImage`, `DiscordBotClient-mac-arm64.dmg` and `DiscordBotClient-mac-x64.dmg`. Windows therefore has a single x64 installer with no arm64 build, while macOS is covered on both architectures. Winget is the only package manager path named, and it is Windows only.
None of these files carries a valid code signing certificate on macOS or Windows, which is stated outright. On Windows the consequence is SmartScreen or Windows Defender raising a flag that has to be bypassed or whitelisted. On macOS the system reports that DiscordBotClient is damaged and can't be opened and should be moved to the Trash, and the remedy offered is a specific comment on issue 194. Handling an unsigned download that your operating system calls damaged is the price of entry to everything else on this page.
The document stops partway through its own symbol legend
The compatibility table ends with a four item legend explaining the app status symbols. The first three are complete: fully functional and expected to be free of critical bugs, at least basic functionality but still under development with minor issues, and major issues such as app startup where use is not recommended. The fourth entry begins with the words This version has reached its end and stops there, and that is where the document text ends.
The table of contents promised eight further sections after it: Troubleshooting, FAQ, About anti virus detection, Similar projects, Star History, how to update to the latest Discord version, Credits and a Disclaimer. None of that text sits behind the legend, so the claims a reader most wants to check, what breaks and how to get help, are not in the document.
The same cut appears in package.json, whose devDependencies list stops mid token after `"electro`. Everything above that line is legible: TypeScript, ESLint 9 with the typescript-eslint plugins at ^8.65.0, and the type packages for express, http-proxy, ini, js-beautify, jsdom, morgan, multer, node and probe-image-size.
Editorial conclusion
Discord's terms discourage third party clients and DiscordBotClient says so on its own front page, so running it means handing a bot token to an unsigned build and accepting that a bad outcome on that account has no appeal. It earns its place only for the piece it adds to the official API: a real client window with Vencord built in. Before trusting any artifact, match the compatibility table against your Discord build number, check that the commit date is newer than the release you are about to download, and decide for yourself whether an unsigned installer is a price you want to pay.
Frequently asked questions
What does DiscordBotClient add that a plain Discord bot library does not?
It repackages the Discord desktop client with Electron and adds a first startup login form that accepts a bot account. The shell then behaves like a user session, except that Friends and Groups are left out. Vencord is compiled into the build rather than loaded on top of it.
Which gateway intents does DiscordBotClient need before login works?
The MessageContent intent has to be enabled, and the document calls every other intent optional. Enabling all of them is what it recommends when you want the member list and each member's status.
How many Discord builds does the DiscordBotClient compatibility table cover?
Fifteen rows, from Stable 204762 at client v2.4.2 up to a Latest row whose build, hash and Vencord entries are question marks. Twelve rows are marked EOL, v3.9.1 is Deprecated, and only v3.9.3 is marked Latest.
Are the DiscordBotClient installers code signed?
No. The application is not signed with a valid certificate on macOS or Windows, so Windows may raise SmartScreen or Defender, and macOS may report that DiscordBotClient is damaged and can't be opened. The document points at a comment on issue 194 for that case.
What does running npm test in DiscordBotClient actually do?
The test script is `npm run build:ts && npm run start`, and start is `electron .`, so it compiles the TypeScript and then opens the application. There is no assertion step, and the type only check is the separate `test:typescript` script running `tsc --noEmit`.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/aiko-chan-ai-discordbotclient)