# adobe-discord-rpc turns Adobe app activity into Discord Rich Presence > The adobe-discord-rpc project is a CEP extension that reports your current Adobe application and document to Discord, supports ten apps, ships from GitHub Releases, and warns that Discord changed its RPC API. **teeteeteeteetee/adobe-discord-rpc** — Discord Rich Presence extension for your adobe apps! - Repository: https://github.com/teeteeteeteetee/adobe-discord-rpc - Stars: 670 · Forks: 48 - Language: JavaScript - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/teeteeteeteetee-adobe-discord-rpc ## A panel extension that reports what you are working on adobe-discord-rpc is an extension that connects Adobe applications with Discord and provides information for your profile. It auto-launches when the Adobe app starts, so there is no separate step between opening a file and your status changing. Technically it is a CEP extension, the extension model Adobe used for its Creative Cloud applications, and the project is built on Adobe-Cep-React-Create, which is acknowledged in the README as the foundation. The source tree matches that description. There is a pluginrc.js at the top level, which is the CEP manifest, a src directory with the extension code, build-scripts for the packaging pipeline, tailwind and postcss configuration for the user interface, and a yarn.lock for reproducible dependency resolution. The interesting property of the integration is that it does not merely toggle a status. Discord Rich Presence normally carries a state and details, and for a design tool the meaningful state is the application and the document open in it. The topic list on the repository names the applications involved, Photoshop, Premiere Pro, After Effects, Illustrator, Audition, Animate, Dreamweaver, InDesign and InCopy, along with the extension mechanism itself. For the user, the payoff is small but constant: the status line on a Discord profile reflects the creative work rather than being idle. The cost is that a presence integration depends on somebody else's RPC API staying the same, which is precisely the failure this project warns about. ## Ten supported applications and four documented gaps The support list is explicit, which is more useful than a general claim. Supported applications are After Effects, Photoshop, Premiere Pro, Audition, Illustrator, Animate, Dreamweaver, InDesign and InCopy, and Prelude, which is marked as broken. The word broken rather than unsupported suggests the code path exists and does not work, which is a different situation for a user deciding whether to file a bug. The unsupported list is Media Encoder, Acrobat, Premiere Rush and Lightroom Classic. The difference between the two lists matters technically. Media Encoder is the obvious gap for a video workflow, because it is where an export actually runs, so a user whose status should show an export will not see it. Acrobat and Lightroom Classic sit outside the CEP model that the extension is built on, and Premiere Rush is a newer application with its own extension story. So the coverage is broad enough to be useful for most creative work, and specific enough that a person whose daily tool is on the unsupported list should expect nothing from this project. The repository also links a separate UXP version of the extension that is described as in progress, and UXP is Adobe's newer extension platform. That is the most likely route to broader or more current application coverage, and it is also the route with a different maturity profile. ## Install from Releases, not from a clone The README is unusually direct about this. It asks users not to clone the repository and to get the extension from the Releases page, and there is a separate GUIDE.md that is linked as a simple step-by-step installation guide. The distinction matters because the repository is a development tree with a build pipeline, while the release artefacts are packaged extensions ready to drop into an Adobe application. There is also a warning at the top of the README that has to be read first, because it changes the whole installation decision. It asks users to make sure they are on the latest version, since the RPC API on Discord's side changed. An older build of this extension can simply stop reporting presence, with no error in the Adobe application to explain why. For anyone who installed this a year ago and stopped seeing their status, that is the first thing to check. Apple silicon needs a specific workaround, and it is the most common source of confusion. Users on Apple silicon have to run Photoshop through Rosetta and turn on Legacy Extensions in Preferences, then restart the application. Legacy CEP extensions are a compatibility layer, and the setting has to be enabled per application before the extension will load at all. The support server is linked for reaching out when needed, and the project also has a donation list, which is a reasonable signal about how the work is funded but not something to plan around. ## The build pipeline that produces a release artefact For anyone who wants to build rather than download, the package.json scripts describe the whole pipeline. The developer-facing commands are a webpack dev server for the client, separate build and deploy steps for development and production, and an archive step: ```json "client:dev-server": "webpack-dev-server --config ./build-scripts/webpack.client.config.js --env.target=web --mode development --open", "build:dev": "node ./build-scripts/build.js development", "build:prod": "node ./build-scripts/build.js production", "deploy:dev": "node ./build-scripts/deploy.js development", "deploy:prod": "node ./build-scripts/deploy.js production", ``` The release scripts chain those steps together, with the production release building, deploying and then archiving the result, and there is a separate archive script that packages the built extension: ```json "archive": "node ./build-scripts/archive.js", "release:prod": "npm run build:prod && npm run deploy:prod && npm run archive", "b": "babel ./client/js --out-dir ./client/out", ``` The build tooling is from a specific era. The devDependencies list Babel 6 alongside Babel 7, babel-loader, webpack plugins for extracting and minimising CSS, postcss with tailwindcss typography, and chalk for coloured console output. The presence of both Babel 6 packages and Babel 7 packages in the same list is the kind of detail that predicts friction on a modern Node version. The package identity is also worth reading closely: ```json "name": "discord-rpc", "version": "v0.0.5", "description": "Discord Rich Presence extension for your adobe apps!", ``` The package is named discord-rpc rather than adobe-discord-rpc, and the version in the working tree is v0.0.5. That version is one step ahead of the newest published tag, which is v0.0.4. The tree is ahead of what most users have. ## The Discord API dependency is the real constraint This project does not control the protocol it depends on. Discord's Rich Presence is delivered over a local RPC pipe that the desktop client exposes, and the README's opening warning says the RPC API changed on Discord's side and that users must update to the latest version of the extension to keep working. That dependency shapes how the project is maintained. A Discord client update can change the handshake or the activity payload format, and the only fix is a new build of the extension. The release history shows how that plays out in practice, with a hotfix appearing in the tag name for an earlier release, v0.0.2-hotfix2, published on 2023-11-25. The alternative is the UXP version linked from the README, a separate repository for the newer Adobe extension platform. The difference in approach is architectural. CEP extensions run inside the host application and, in the Apple silicon case, need a compatibility layer and Rosetta, while UXP is the platform Adobe built for new applications and does not depend on the legacy path. The trade-off is maturity, since the UXP version is described as in progress while the CEP version is the one with published releases and a documented install path. The other thing a user can do instead of running this extension is let Discord's own presence features handle the apps it already knows about. The difference in outcome is that Discord's built-in reporting covers games and a limited set of applications with a game-like model, while this project reports a design or editing session in an Adobe tool, which is the part Discord does not model. ## Two licences, no test suite, an old release There are some rough edges in the repository that an adopter should see. The licence is stated twice and differently. The repository listing carries a LICENSE file, and the licence recorded for the repository is MIT, while the license field inside package.json says ISC. Those are two permissive licences with different notice obligations, and a project that publishes a binary artefact under one of them should not leave the other in the metadata. Anyone distributing the extension should settle that before shipping it. The test story is that there is no test story. The test script in package.json is the npm default for a project with no tests, and it echoes a message that no test is specified and exits with a failure. For an extension that talks to a protocol owned by another company, that is the exact area where a regression test would pay for itself. The release history is thin. The published tags are v0.0.4 on 2025-01-24, v0.0.3 on 2024-04-19 and v0.0.2-hotfix2 on 2023-11-25, so the last published artefact is about a year older than the working tree, which sits at v0.0.5. The last push to the repository was on 2026-08-04. That gap is what makes the README's warning actionable: a user who downloads the newest tag is not necessarily running the newest code, and the Discord API may have moved since. For a personal creative tool, none of this is a blocker. For a studio that standardises on it, the missing tests, the duplicated licence and the gap between the tree and the published build are three things to fix before anyone depends on it. ## Conclusion adobe-discord-rpc fits a designer or editor who wants Discord to show what they are working on, and who can install a legacy CEP extension and accept that a Discord API change can break the integration without warning. It is the wrong choice for a team that needs a supported, tested extension, since the repository carries no test suite, the published build lags the working tree, and the licence is stated two different ways. Before installing, read GUIDE.md rather than the README, check the release page for a build that works with the current Discord client, and on Apple silicon expect to run the app through Rosetta with Legacy Extensions enabled. ## FAQ ### How do I install the Adobe Discord Rich Presence extension? The README asks users not to clone the repository and to download the extension from the GitHub Releases page, with a step-by-step guide in GUIDE.md. On Apple silicon, Photoshop has to be run through Rosetta and Legacy Extensions turned on in Preferences before restarting the application. ### Which Adobe applications does adobe-discord-rpc support? The supported list covers After Effects, Photoshop, Premiere Pro, Audition, Illustrator, Animate, Dreamweaver, InDesign, InCopy and Prelude, which is marked as broken. Media Encoder, Acrobat, Premiere Rush and Lightroom Classic are listed as unsupported. ### Why did my Discord status stop updating in the Adobe apps? The README warns that the RPC API changed on Discord's side, so an old build of the extension can stop working without any error inside Adobe. Update to the latest release, and remember that the newest published tag may be older than the working tree. ### What licence is adobe-discord-rpc released under? The repository is recorded as MIT licensed with a LICENSE file, while the license field in package.json says ISC. The two are both permissive but differ in their notice requirements, so check the LICENSE file before redistributing the extension. ## Sources - [Issues](https://github.com/teeteeteeteetee/adobe-discord-rpc/issues) - [License: MIT](https://github.com/teeteeteeteetee/adobe-discord-rpc/blob/master/LICENSE) - [README](https://github.com/teeteeteeteetee/adobe-discord-rpc/blob/master/README.md) - [Releases](https://github.com/teeteeteeteetee/adobe-discord-rpc/releases) - [teeteeteeteetee/adobe-discord-rpc on GitHub](https://github.com/teeteeteeteetee/adobe-discord-rpc) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/teeteeteeteetee-adobe-discord-rpc