Work in progress

The content of this page was not yet updated for Godot 4.0 and may be outdated. If you know how to improve this page or you can confirm that it's up to date, feel free to open a pull request.

Command line tutorial

Some developers like using the command line extensively. Godot is designed to be friendly to them, so here are the steps for working entirely from the command line. Given the engine relies on almost no external libraries, initialization times are pretty fast, making it suitable for this workflow.


On Windows and Linux, you can run a Godot binary in a terminal by specifying its relative or absolute path.

On macOS, the process is different due to Godot being contained within an .app bundle (which is a folder, not a file). To run a Godot binary from a terminal on macOS, you have to cd to the folder where the Godot application bundle is located, then run followed by any command line arguments. If you've renamed the application bundle from Godot to another name, make sure to edit this command line accordingly.

Command line reference

General options



-h, --help

Display the list of command line options.


Display the version string.

-v, --verbose

Use verbose stdout mode.

-q, --quiet

Quiet mode, silences stdout messages. Errors are still displayed.

Run options




Separator for user-provided arguments. Following arguments are not used by the engine, but can be read from OS.get_cmdline_user_args().

-e, --editor

Start the editor instead of running the scene (target=editor must be used).

-p, --project-manager

Start the Project Manager, even if a project is auto-detected (target=editor must be used).

--debug-server <uri>

Start the editor debug server (<protocol>://<host/IP>[:<port>], e.g. tcp://


Quit after the first iteration.

-l, --language <locale>

Use a specific locale. <locale> follows the format language_Script_COUNTRY_VARIANT where language is a 2 or 3-letter language code in lower case and the rest is optional. See Locale codes for more details.

--path <directory>

Path to a project (<directory> must contain a 'project.godot' file).

-u, --upwards

Scan folders upwards for 'project.godot' file.

--main-pack <file>

Path to a pack (.pck) file to load.

--render-thread <mode>

Render thread mode ('unsafe', 'safe', 'separate'). See Thread Model for more details.

--remote-fs <address>

Remote filesystem (<host/IP>[:<port>] address).

--remote-fs-password <password>

Password for remote filesystem.

--audio-driver <driver>

Audio driver. Use --help first to display the list of available drivers.

--display-driver <driver>

Display driver (and rendering driver). Use --help first to display the list of available drivers.

--rendering-method <renderer>

Renderer name. Requires driver support.

--rendering-driver <driver>

Rendering driver (depends on display driver). Use --help first to display the list of available drivers.

--gpu-index <device_index>

Use a specific GPU (run with --verbose to get available device list).

--text-driver <driver>

Text driver ('Fonts', 'BiDi', 'shaping')

--tablet-driver <driver>

Pen tablet input driver.


Enable headless mode (--display-driver headless --audio-driver Dummy). Useful for servers and with --script.

--write-movie <file>

Run the engine in a way that a movie is written (by default .avi MJPEG). Fixed FPS is forced when enabled, but can be used to change movie FPS. Disabling vsync can speed up movie writing but makes interaction more difficult.


Force disabling of vsync. Run the engine in a way that a movie is written (by default .avi MJPEG). Fixed FPS is forced when enabled, but can be used to change movie FPS.

Display options



-f, --fullscreen

Request fullscreen mode.

-m, --maximized

Request a maximized window.

-w, --windowed

Request windowed mode.

-t, --always-on-top

Request an always-on-top window.

--resolution <W>x<H>

Request window resolution.

--position <X>,<Y>

Request window position.


Use a single window (no separate subwindows).

--xr-mode <mode>

Select XR mode (default/off/on).

Debug options


Debug options are only available in the editor and debug export templates (they require debug or release_debug build targets, see Target for more details).



-d, --debug

Debug (local stdout debugger).

-b, --breakpoints

Breakpoint list as source::line comma-separated pairs, no spaces (use %20 instead).


Enable profiling in the script debugger.


Show a GPU profile of the tasks that took the most time during frame rendering.


Enable graphics API validation layers for debugging.


Abort on GPU errors (usually validation layer errors), may help see the problem if your system freezes.

--remote-debug <uri>

Remote debug (<protocol>://<host/IP>[:<port>], e.g. tcp://


Show collision shapes when running the scene.


Show path lines when running the scene.


Show navigation polygons when running the scene.


Print all StringName allocations to stdout when the engine quits.

--frame-delay <ms>

Simulate high CPU load (delay each frame by <ms> milliseconds).

--time-scale <scale>

Force time scale (higher values are faster, 1.0 is normal speed).


Disable render loop so rendering only occurs when called explicitly from script.


Disable crash handler when supported by the platform code.

--fixed-fps <fps>

Force a fixed number of frames per second. This setting disables real-time synchronization.


Print the frames per second to the stdout.

Standalone tools



-s, --script <script>

Run a script.


Only parse for errors and quit (use with --script).

--export-release <preset> <path>

Export the project using the given preset and matching release template (target=editor must be used). The preset name should match one defined in export_presets.cfg. <path> should be absolute or relative to the project directory, and include the filename for the binary (e.g. 'builds/game.exe'). The target directory should exist.

--export-debug <preset> <path>

Like --export-release, but use debug template (target=editor must be used).

--export-pack <preset> <path>

Like --export-release, but only export the game pack for the given preset. The <path> extension determines whether it will be in PCK or ZIP format (target=editor must be used).

--convert-3to4 [<max_file_kb>] [<max_line_size>]

Convert project from Godot 3.x to Godot 4.x.

--validate-conversion-3to4 [<max_file_kb>] [<max_line_size>]

Show what elements will be renamed when converting project from Godot 3.x to Godot 4.x.

--doctool <path>

Dump the engine API reference to the given <path> in XML format, merging if existing files are found (target=editor must be used).


Disallow dumping the base types (used with --doctool, target=editor must be used).


Build the scripting solutions (e.g. for C# projects, target=editor must be used). Implies --editor and requires a valid project to edit.


Generate GDExtension header file 'gdnative_interface.h' in the current folder. This file is the base file required to implement a GDExtension.


Generate JSON dump of the Godot API for GDExtension bindings named 'extension_api.json' in the current folder (target=editor must be used).


Benchmark the startup time and print it to console.

--startup-benchmark-file <path>

Benchmark the startup time and save it to a given file in JSON format.


It is recommended that your Godot editor binary be in your PATH environment variable, so it can be executed easily from any place by typing godot. You can do so on Linux by placing the Godot binary in /usr/local/bin and making sure it is called godot (case-sensitive).

Setting the project path

Depending on where your Godot binary is located and what your current working directory is, you may need to set the path to your project for any of the following commands to work correctly.

This can be done by giving the path to the project.godot file of your project as either the first argument, like this:

godot path_to_your_project/project.godot [other] [commands] [and] [args]

Or by using the --path argument:

godot --path path_to_your_project [other] [commands] [and] [args]

For example, the full command for exporting your game (as explained below) might look like this:

godot --path path_to_your_project --export-release my_export_preset_name game.exe

Creating a project

Creating a project from the command line can be done by navigating the shell to the desired place and making a project.godot file.

mkdir newgame
cd newgame
touch project.godot

The project can now be opened with Godot.

Running the editor

Running the editor is done by executing Godot with the -e flag. This must be done from within the project directory or a subdirectory, otherwise the command is ignored and the Project Manager appears.

godot -e

If a scene has been created and saved, it can be edited later by running the same code with that scene as argument.

godot -e scene.tscn

Erasing a scene

Godot is friends with your filesystem and will not create extra metadata files. Use rm to erase a scene file. Make sure nothing references that scene. Otherwise, an error will be thrown upon opening the project.

rm scene.tscn

Running the game

To run the game, simply execute Godot within the project directory or subdirectory.


When a specific scene needs to be tested, pass that scene to the command line.

godot scene.tscn


Catching errors in the command line can be a difficult task because they scroll quickly. For this, a command line debugger is provided by adding -d. It works for running either the game or a single scene.

godot -d
godot -d scene.tscn


Exporting the project from the command line is also supported. This is especially useful for continuous integration setups. The version of Godot that is headless (server build, no video) is ideal for this.

# `godot` must be a Godot editor binary, not an export template.
# Also, export templates must be installed for the editor
# (or a valid custom export template must be defined in the export preset).
godot --export-release "Linux/X11" /var/builds/project
godot --export-release Android /var/builds/project.apk

The preset name must match the name of an export preset defined in the project's export_presets.cfg file. If the preset name contains spaces or special characters (such as "Windows Desktop"), it must be surrounded with quotes.

To export a debug version of the game, use the --export-debug switch instead of --export. Their parameters and usage are the same.

To export only a PCK file, use the --export-pack option followed by the preset name and output path, with the file extension, instead of --export. The output path extension determines the package's format, either PCK or ZIP.


When specifying a relative path as the path for --export-release, --export-debug or --export-pack, the path will be relative to the directory containing the project.godot file, not relative to the current working directory.

Running a script

It is possible to run a .gd script from the command line. This feature is especially useful in large projects, e.g. for batch conversion of assets or custom import/export.

The script must inherit from SceneTree or MainLoop.

Here is an example, showing how it works:

#!/usr/bin/env -S godot -s
extends SceneTree

func _init():

And how to run it:

# Prints "Hello!" to standard output.
godot -s

If no project.godot exists at the path, current path is assumed to be the current working directory (unless --path is specified).

The first line of above is commonly referred to as a shebang. If the Godot binary is in your PATH as godot, it allows you to run the script as follows in modern Linux distributions, as well as macOS:

# Mark script as executable.
chmod +x
# Prints "Hello!" to standard output.

If the above doesn't work in your current version of Linux or macOS, you can always have the shebang run Godot straight from where it is located as follows:

#!/usr/bin/godot -s