SketchUp 2026.2 broke SketchupExtension#load_on_start? It now only returns false

[Whaat]

We rely on this method in our Double-Cut extension.

Since 2026.2 was released, this is broken and has also broken our extension. Please fix this asap. Thank you.

Extensions marked Enabled should return 'true' for load_on_start? but in 2026.2, it always returns false

[Fredosixx]

I confirm the bug. On SU2026.2, all extensions return false for the method load_on_start (while they are definitely loading on startup).

In SU2025 with the same installation of extensions, the return value is true

I use this line of code in the Ruby Console:

Sketchup.extensions.each { |a| puts "#{a.name} - #{a.load_on_start?}" }

[DanRathbun]

I also see this behavior. That said, the #loaded? method is the query method to determine if an extension is "working". (withdrawn)

The Sketchup::register_extension method is supposed to update the @load_on_start variable, which is initialized to false.

[kalpana-ghodeswar]

Thanks, ticket logged SKEXT-5285.

[Eneroth3]

This may be related to some lower level changes in the SketchUp load order 🤔

May I ask what the extension uses this for? If an extension is disabled, it should not be doing anything, other than define the SketchupExtension metadata. Are there cases when you want to differentiate an extension loaded temporarily in this session from when it is set to load automatically?

[Whaat]

Let's say you have a plugin that performs many actions based on Observers being triggered. That's Double-Cut. Some users want to disable the plugin and observers temporarily for whatever reason. Users expect that if they disable the extension in Extension Manager, then the plugin behaviors (observers) will immediately stop working. So we use this method to check if the user wants to disable the plugin (load_on_start = false). If so, our observers do not perform their actions. It allows the user to easily toggle the observer behaviors off or on without the hassle of restarting SketchUp in the middle of a some task.

I think we implemented this because users contacted us expecting that disabling the plugin would immediately prevent the plugin from working, which of course it didn't because SketchUp can't unload the plugin code.

There might be other ways we are using this method, I'd have to dig deeper to confirm.

[DanRathbun]

There is also the AppObserver#onUnloadExtension callback, (which is really a "user has disabled the extension in EM" callback.) But no complimentary callback that fires when an extension is re-enabled after the load cycle.

[Eneroth3]

Thanks for the additional info!

I wish the API could automatically disable observers when an extension is disabled so we don't need these work-arounds 🥲.

I'll add some notes to our internal ticket about this issue. I do not know when a fix can be realistically released though. In the meantime I'd recommend looking for alternative solutions like using the observer Dan mentioned and accept the extension cannot be re-enabled within the same session, or not disabling it.

[Fredosixx]

I do not know when a fix can be realistically released though

The issue logged is a major regression of SU2026.2, not a feature request. It is a bug. It works fine in SU2025.

Are you going to update the documentation by saying 'As of SU2026, this method does not work as intended and always returns false'?

[DanRathbun]

That said, the #loaded? method is the query method to determine if an extension is "working".

I take this back after some thought and rereading the "Tools/extension.rb" file. The @loaded variable is set true even if an attempt is made to load it. If the load fails, say in one of the extension's files and an exception is raised, the rescue block in load() still sets the variable to true.

---

An extension might keep it's own internal @enabled variable and if it gets disabled (via the EM per AppObserver#onUnloadExtension,) could provide a menu item command to reenable the extension.