Enable users to turn on external plugins via configuration within desktop app.

[lukasonokoleg]

• I agree to follow the Code of Conduct that this project adheres to.

• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Is your feature request related to a problem? Please describe.

_The desktop application supports external plugins only when started with the --enable-plugins command-line flag. While this is a reasonable security default, many users are unaware that the feature exists or have no practical way to enable it, especially on Windows and macOS where applications are typically launched from shortcuts or the application launcher rather than a terminal.

This makes it unnecessarily difficult for users who consciously want to use trusted third-party plugins._

Describe the solution you'd like
_Provide an optional UI setting that allows users to enable external plugins after explicitly acknowledging the security implications.

For example:

• Settings → Advanced
  • ☐ Enable external plugins
• Display a warning explaining that external plugins execute arbitrary JavaScript and should only be enabled for trusted plugins.
• Require confirmation before enabling the setting.
• Store the preference locally and apply it on subsequent launches.

This would preserve the secure default while making the feature accessible to users who intentionally choose to use external plugins._

Describe alternatives you've considered
The current --enable-plugins startup flag works technically but has several usability issues:

• Many users never launch draw.io from a terminal.
• Windows users must manually modify shortcuts.
• macOS users must create custom launchers or always use the command line.
• Plugin authors must explain platform-specific startup instructions instead of simply documenting how to install their plugin.

Another possibility would be a first-run dialog when an external plugin is detected, asking whether the user wishes to enable support.

Additional context

External plugins significantly expand what draw.io Desktop can do beyond its built-in functionality. They enable communities, companies, and open-source projects to create domain-specific extensions such as custom diagram types, opinionated shape libraries, validation rules, generators, import/export capabilities, and workflow automation that would not be practical to include in the core product.

By providing an official, user-controlled way to enable external plugins, draw.io can foster a richer extension ecosystem while maintaining a secure-by-default experience. Users who need specialized functionality can consciously opt in after understanding the security implications, while everyone else continues to benefit from the existing secure default.

This allows draw.io to remain a lightweight, general-purpose diagramming tool while empowering the community to build specialized capabilities for enterprise architecture, cloud infrastructure, networking, Kubernetes, BPMN extensions, C4 modeling, industry-specific notations, and many other use cases without increasing the maintenance burden of the core application.

[davidjgraph]

I've thought about the issue in some detail of the past weeks and I've come to the position that I want the plugin functionality removed entirely from the codebase.

• The plugin architecture has been a consistent expansion of the security attack surface of the app. That ties into:
• The plugin architecture allows arbitrary JS (within the conditions you describe, which are intentionally harsh to setup) to be run under our official signing of the app. I simply don't want this.

One way that you're right is that the setup is too harsh and the conclusion from that is make it less harsh or remove it entirely. So, I'm going to remove it entirely.

LLMs exist at a point that it's perfectly easy to have them make the changes to the codebase and to adapt the app with moderate complexity changes.

[lukasonokoleg]

Hi @davidjgraph,

Thank you for taking the time to think this through and for providing a detailed explanation. I appreciate the transparency behind the decision.

I completely agree that executing arbitrary JavaScript inside a signed desktop application increases the attack surface, and I understand why that is a concern from a maintainer’s perspective.

Where I see the trade-off differently is that I don’t think extensibility and security are necessarily mutually exclusive.

For example, VS Code extensions also execute with the full privileges of the application, yet Microsoft has chosen to mitigate the risk through layered trust rather than removing extensibility altogether. They rely on mechanisms such as publisher identity, marketplace validation, enterprise allow-lists, user consent, and Workspace Trust. The attack surface still exists, but it is managed through explicit trust decisions instead of being eliminated.

My use case was never to enable arbitrary third-party JavaScript from the Internet. The goal was to allow organizations and advanced users to intentionally install trusted extensions that add opinionated functionality—for example, domain-specific diagram types, custom shapes, architecture validations, or integrations that are outside the scope of the core application.

An opt-in model (disabled by default, with explicit user acknowledgement) seemed like a reasonable balance to me, similar to how many developer tools approach extensibility.

That said, I also respect that this is ultimately an architectural decision for the project, and if your conclusion is that the official desktop application should not support extensibility at all, I understand that position.

Thank you again for taking the time to explain your reasoning.

I hope - that yet decision is not final - and there is a possibility to enable community to have extensions.

[davidjgraph]

Just a hint, pasting walls of AI generated text doesn't work with me. Happy to discuss with humans, not claude.

[lukasonokoleg]

@davidjgraph - apologies for walls of AI Generated text. Just as english is not may native - I tend to use it to form my thoughts more nicely.

Going back to plugins topic - My personal feeling - that loosing them is a huge potential loss. And I was thinking, that for example VSCode won a lot with extentions capability they have. And VSCode is also javascript based.

So I was thinking - maybe there could be an option, when plugins stays - and for example users are confirming installation of plugins - with extensive note - that it is on them own.

Another, thought - maybe there could be sort of open registry of plugins - where people share their plugins - and then community rates those.

From DrawIo - perspective - apart of ones which are already backed in - it is consumers problem/responsibility regarding plugins it installs.

P.S.

• Once more time apologies for AI Generated text.

[davidjgraph]

I don't want the extra work of managing plugins, etc. Community rating doesn't matter, we're the ones liable if there's a security problem.

AI coders are at the point that it's very easy to make your adapted build of draw.io that includes the plugin functionality. If someone provides an example plugin we can show the whole process of creating that build.

[ViViVerse]

Any plugin constitutes a security problem in almost any application. That should not be the reason for abolishing this functionality altogether. With plugins, DrawIO is an incredibly useful tool for visualising complex systems, but also for creating these systems - which is, what I wanted to use it for. Without plugins, it seems to be only a drawing app to me, which I reckon a shame.
I would really appreciate guidance on how to extend the functionality in a way comparably simple to the plugin mechanism.
Many thanks

[pdestrais]

Hello @davidjgraph , I've created a new UI element that I would like to add to draw.io desktop using the plugins mechanism.
As this is now blocked, I'd like to create my own build of draw.io that includes the plugin functionality.
What is the process to follow ?

[davidjgraph]

please link to the plugin code

[pdestrais]

mxMyContainerShape.js

@davidjgraph , is it enough ?

[pdestrais]

Hello @davidjgraph, as you proposed earlier, can you describe the process of creating an adapted build of draw.io that includes the plugin functionality ?

[davidjgraph]

I'm on holiday every august for the entire month.