godot-console: an in-game console for Godot 3 you can extend

A console that exists to run your own commands

godot-console is an in-game console for Godot, and the README says it can be easily extended with new commands. That framing is the whole point. The addon is not a debug log viewer or a remote control panel, it is a command line inside the game that you extend with your own verbs.

The usage it aims at looks like this. A command is typed with a dollar sign and a name, and an argument follows in quotes, so the line is sayHello "Adam Smith", and the response printed back is Hello Adam Smith!.

That is a small interface, but it is the right one for a game. It means a designer or a QA person can trigger a state change, teleport a character, spawn an item or dump a value without a build, and the person writing the feature writes the command next to the feature.

The plugin lives in the addons directory of the project, split across two folders, @quentincaffeino and quentincaffeino, and is enabled as a plugin from the project settings rather than added to a scene. Once enabled, the console is toggled while the game is running with CTRL and the backtick key, and the README notes that this can be changed through the input map, where the action is named quentincaffeino_console_toggle.

The audience is Godot 3 developers who want a debug surface that survives into a shipped build, and who want to add to it rather than maintain a separate tooling channel.

Commands are registered as a chain of calls

The registration API is a fluent chain, and the GDScript example in the README is the clearest description of the contract.

# Function that will be called by our command
func print_hello(name = ''):
	Console.write_line('Hello ' + name + '!')

func _ready():
	# Registering command
	# 1. argument is command name
	# 2. arg. is target (target could be a funcref)
	# 3. arg. is target name (name is not required if it is the same as first arg or target is a funcref)
	Console.add_command('sayHello', self, 'print_hello')\
		.set_description('Prints "Hello %name%!"')\
		.add_argument('name', TYPE_STRING)\
		.register()

Three things are being defined. The command name, the target object the command runs against, and the name of the method on that target. The target does not have to be a node with a matching name, because the third argument can be left out when it is the same as the first or when the target is a FuncRef.

That FuncRef option is listed as a separate feature, supported with Godot 3.2 and newer, and it is what makes the console usable from other scripts. A command can point at a callable rather than at a method on the object that registered it, so a global command can be attached to a singleton or to a resource and still be dispatched.

The description string uses a percent sign placeholder for the argument, and arguments carry a type, here TYPE_STRING. The description is what the autocomplete shows, so it is user interface rather than documentation.

Autocomplete, history and output that also reaches the engine log

Three details make the console feel like a shell rather than a prompt box.

Autocomplete works with the TAB key, so a half typed command can be completed from what is registered. Session command history is kept and navigated with the UP and DOWN arrow keys, so a command that worked a minute ago can be recalled. And the size of that history is configurable, though not through the plugin interface: the README says to change the current NUMBER in Console.gd at line 30, where the history is constructed as a preload of Misc/History.gd with that number as its argument.

That last point is the kind of detail that tells you the age and the priorities of the project. A configuration value that is edited in the source of the addon, at a fixed line number, is not ideal, but it is a small thing and the alternative would have been a settings screen.

Output goes through the write and write_line methods, and the README notes that it is also printed to the engine output. That is a deliberate convenience: the same message appears in the in-game console and in the editor's output panel, so a tester can see it and a developer can read the log. BB codes are supported in the output, which is the RichTextLabel markup in Godot, so colour and formatting in the console are possible without escaping.

The combination means the console is usable as the game's own log surface during development, not only as a command entry point.

Flexible types decide what a command argument can be

The type documentation is a separate document in the addon, and it is the part that decides how much a command can do.

The README lists three groups under flexible types. Engine types are the ones Godot already defines. Extra types are additions the addon provides. And custom types are the third case, with a section on creating them.

This matters because a command that only accepts strings can still change a game's state, but a command that accepts a vector, a colour, a node reference or a resource is far more useful, and doing that by parsing strings in every command would be repetitive. A type system in the argument definition means the value arrives already typed, and the custom type case means a project can add its own domain types to the same mechanism.

The trade-off is that argument types are declared at registration time, so a command with a fixed signature needs a separate command, or a type that can absorb several shapes, if the input varies. The README does not document how a command with an optional argument is declared, which is one of the things to look for in the generated documentation under the addons console docs folder.

Installing means copying two folders and ticking a checkbox

There are two documented routes and they amount to the same result.

The first is the editor's AssetLib. You open AssetLib, search for Console in the Scripts category, open the entry, download and install it, and the package installer copies the file structure as it is, which adds two directories to your project, addons/@quentincaffeino/* and addons/quentincaffeino/*.

The second is Git. You clone the project or download the latest release archive, and copy the addons/@quentincaffeino and addons/quentincaffeino folders into your own project's addons directory. The README shows the resulting project structure with those two folders sitting side by side under addons.

Either way the last two steps are identical. You open Project > Project Settings > Plugins, search for quentincaffeino-console, and check the Enable checkbox. Then, while the game is running, CTRL plus backtick opens the console, and the same key combination is bound to the quentincaffeino_console_toggle action in the input map if you want to change it.

The reason for the two directory names is that the addon ships two plugin entries, which the C# section comes back to.

C# reaches the same API by call, then by a wrapper that is unfinished

The C# story has two stages, and the README is clear that the second one is not finished.

The direct route calls the same methods the GDScript API exposes, through the Godot object at the root of the tree. Because C# has no equivalent of a fluent chain on a dynamic object, the calls are chained through Cast calls, which is verbose but does the same work.

public override void _Ready()
{
    _wrapper = GetTree().Root.GetNode<Console>("CSharpConsole");
    _wrapper.AddCommand("sayHello", this, nameof(PrintHello))
            .SetDescription("prints \"hello %name%!\"")
            .AddArgument("name", Variant.Type.String)
            .Register();
}

public void PrintHello(string name = null) {
    GD.Print($"Hello {name}!");
}

The wrapper is the nicer form, with the same method names as the GDScript API but typed for C#, and it needs a different plugin: instead of enabling the Console checkbox in the addon tab you enable CSharpConsole through the plugin checkbox. The README labels this section as work in progress and warns that some methods may be missing, so the C# API surface is not complete.

The repository has a separate demo-csharp directory alongside the GDScript demo, so both paths have runnable examples, and the topics list includes csharp, which tells you the C# side is a first class goal rather than an afterthought. It is also the reason there are two plugin folders, since each has to be enabled separately.

Godot 3 only, and releases that stopped in 2022

Two facts bound how you should think about this project.

The first is the engine. The repository description says in-game console for Godot 3, the requirements mention FuncRef support with Godot 3.2 and newer, and the GDScript API shown in the examples is the Godot 3 style, with a tab indented script and a project settings path from that era. This is not a Godot 4 addon, and the documentation does not describe a port.

The second is the release history. The tags are v3.6.0 from 2022-11-13, v3.5.1 from 2021-12-24 and v3.5.0 from 2021-12-04, so the newest published release is nearly four years old. The last push was on 2026-08-29 and the repository is not archived, and the default branch is develop rather than master, which suggests the work continues on a development branch without new tagged releases.

The maintenance machinery around it is modern enough to say something about the project's health. The package.json is a private workspace root whose test script runs pnpm -r test, with GUT 7.3.0 as the test framework, and there is a renovate.json for dependency updates. The Makefile drives the demo with run-demo and run-demo-editor targets, and a generate-docs target that runs a binary from the gdscript-docs-maker directory to produce the generated documentation under the addons console docs folder, which is where the API reference the README links to comes from.

So the code is being worked on, the docs are generated, and the releases are not. For a plugin pinned to an engine generation that is no longer current, that is the central question for anyone still on Godot 3, and the answer is to vendor the addon and read the generated docs rather than to wait for a release.

Editorial conclusion

godot-console fits a team still on Godot 3 that wants a debug command surface inside the shipped game and is willing to extend it with its own verbs. It does not fit a Godot 4 project, and the tagged releases stop at v3.6.0 from 2022-11-13, so the addon has to be vendored rather than upgraded. Before adopting it, enable the plugin in Project Settings and confirm the toggle action quentincaffeino_console_toggle does not clash with an input your game already uses.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. quentincaffeino/godot-console on GitHub
4. README
5. Releases