Skip to content

Project detection

When you open a folder, Forge looks for a project.godot file in the root. If it finds one, the workspace switches into Godot mode.

Forge in Godot mode: GODOT pill in the title bar, MCP · Godot MCP connected, project tree showing assets / scenes / scripts / project.godot, and the Inspector showing the Godot project panel with Run / Live editor controls and a hierarchy tree

Detection is a single check, run once when the project opens. It’s deliberately cheap: no walking the tree, no probing Godot’s binary, nothing that depends on having Godot installed.

  • A Godot pill in the title bar showing the engine version.
  • A Scene tab in the Inspector that parses .tscn files.
  • An Outline tab that lists members of the active .gd file.
  • Skills tagged for Godot fire when their version constraint matches.

If your project doesn’t have project.godot in the root (a stripped-down asset library, a plugin repo, etc.), Forge stays in plain Project mode. You can still edit .gd and .tscn files normally, you just won’t get the Godot-specific Inspector tabs.

Forge reads the version from project.godot’s [application] section. The relevant line looks like:

[application]
config/features=PackedStringArray("4.5", "Forward Plus")

The first numeric entry in config/features is taken as the engine version. In the example above, Forge reports 4.5 and gates skills with engine: godot, engine_version: ">=4.5" to projects on 4.5 or newer.

If the line is missing or malformed, Forge surfaces the project as “Godot (version unknown)” and skills with no version constraint still fire.

If you want Forge to be able to run Godot from a task (headless export, command-line tooling), it needs to know where the binary is. Resolution order:

  1. The GODOT environment variable, if set.
  2. A user-set path from Settings → Workspace → Godot binary.
  3. PATH, looking for godot, godot4, then Godot_v4.

The settings entry is the right place for most users. Pick the binary once and Forge remembers it.