If you are an agent, or you are automating Summer, the answer is almost always the
first row. An editor plugin is a text file you write and a line you add to
project.godot. It needs no build step, no signing, and no engine source, and it hands
you the entire EditorInterface — which is the only way to reach a large set of engine
capability that is simply not exposed to ordinary scripts.
Editor plugins
A@tool script extending EditorPlugin, declared by a plugin.cfg in
addons/<name>/, enabled through project.godot. It runs inside the editor process
with full editor context.
This is the path that turns “the API is not exposed to scripting” into “the API is
reachable”. Occluder baking, forcing the import of a file an agent just wrote, saving a
scene from code, registering an autoload — none of those are available to a plain
script, and all of them are available from inside an editor plugin.
It also works without a window. Summer --headless --editor boots the editor, loads
enabled plugins, and gives you a live EditorInterface from a shell.
Editor plugins
GDExtension
Native shared libraries loaded from a.gdextension file. No engine recompile, no
custom binary — the same mechanism stock Godot uses.
Summer currently follows the 4.7.2-stable base. Generate the interface and API from the
installed Summer binary rather than reusing headers from an older release. Match the exact
API, architecture, operating system, compiler/runtime dependencies, and signing requirements,
then run a real load/export test; the current compatibility range is not yet measured.
GDExtension
Engine modules
C++ compiled directly into the binary. This requires building the engine from source, and Summer’s engine source is not public, so modules are not an option for external developers today. The page exists because the distinction matters when an upstream tutorial describes an extension mechanism.Engine modules
Using community Godot addons
Community addons are candidates, not blanket-compatible inventory. Pure GDScript addons are usually lower-risk than native extensions, but Summer’s minimum and recommended project compatibility ranges remain unmeasured. Judge every addon by these rules:- Godot 4.7 or 4.x, pure GDScript,
@tool+EditorPlugin— the lower-risk case. No ABI, no compilation, no signing. Install intoaddons/and enable it like any plugin you wrote yourself. - Godot 4.x with a GDExtension binary — depends on the addon shipping a build for 4.7 and for your platform. A successful upstream load is useful evidence, not proof of a Summer load or export. Check GDExtension, then test the exact binary in a committed copy.
- Godot 3.x — dead. The 3.x plugin API does not exist in 4.x. This is not a Summer limitation; the same addon fails on stock Godot 4.
- Anything shipped as an engine module or a custom engine build — cannot be used. There is no way to compile it into Summer.
Next steps
Editor plugins
Headless scripting
Need help? Ask in Discord first. That is where you get the fastest reply and support. For concrete help, email support@summerengine.com or founders@summerengine.com.

