Top-level commands

cg itself, plus the commands that don't belong to a group--logging in, checking who you are, and inspecting session state.

Every command also accepts -h / --help.

Command	Summary
cg	--
cg content-hash	Compute a content hash from stdin content.
cg login	Log in and save the credentials. By default, opens a browser window for the user to log in interactively.
cg logout	Log out of a given profile's session.
cg whoami	Show the current logged-in user and other session info for the given profile.
cg status	Summarize the current session: login status, profile details, and points/rank stats for the logged-in codingamer.
cg doc	Open the documentation for this version of cg in a dedicated browser window.
cg play	Run the solution for whatever file you name against its working directory's test cases, whether that's a puzzle or a contribution.
cg vscode	Editor integration for VS Code. All-or-nothing opt-in: nothing here is written unless you ask for it, and what is written is confined to entries cg names as...
cg vscode install	Install cg's VS Code run/debug configuration.
cg debug	Debug-session commands that work in any working directory, puzzle or contribution.
cg debug start	Build the debug profile and start a stopped debug target fed by the working directory's selected test case, ready for a debugger to attach.
cg debug stop	Stop a debug target started by cg debug start.
cg contributions	List server-side contributions, one line per contribution (handle, id, status, puzzle type, title).

cg

Codingame client command-line interface.

usage: cg [-h] [--trace-http] [--profile PROFILE] [--json] [--config PATH]
          [--log-level {DEBUG,INFO,WARNING,ERROR,CRITICAL}] [--tb] [--input-file INPUT_FILE]
          [--output-file OUTPUT_FILE]
          COMMAND ...

Options

• --trace-http — Log detailed HTTP info (method, URL, headers, cookies) at DEBUG level.
• -p, --profile PROFILE — Profile name to store credentials and browser session state under. Defaults to the client's default profile.
• -j, --json — Where supported, output information in JSON format.
• -c, --config PATH — Explicit config.yaml file, or a directory containing config/config.yaml. Overrides the normal discovery search (see cg config where). Same as the CG_CONFIG environment variable; this flag takes precedence if both are set.
• -l, --log-level {DEBUG,INFO,WARNING,ERROR,CRITICAL} (default: WARNING) — Logging level (default: WARNING).
• --tb — Display full traceback on error.
• -i, --input-file INPUT_FILE — Read from the given file instead of stdin. Reopens sys.stdin for the duration of the command.
• -o, --output-file OUTPUT_FILE — Write to the given file instead of stdout. Reopens sys.stdout for the duration of the command.

Subcommands

• content-hash — Compute a content hash from stdin content.
• login — Log in and save the credentials. By default, opens a browser window for the user to log in interactively.
• logout — Log out of a given profile's session.
• whoami — Show the current logged-in user and other session info for the given profile.
• status — Summarize the current session: login status, profile details, and points/rank stats for the logged-in codingamer. Always hits the network--there's no cached/local mode, unlike cg contribution status/cg puzzle status (that's the whole point of this command). "Gamer stats" are informational, not a breakdown of one another--see CgCodingamePointsRankingDto's docstring for why. With --json (top-level option), renders as JSON instead of text.
• doc — Open the documentation for this version of cg in a dedicated browser window. The published site keeps every release side by side, so this opens the directory matching the cg you are actually running rather than whatever is newest. Inside a source checkout it serves that tree's own docs instead--including uncommitted edits--and stops the server when the window closes. With --url, prints the address and exits, which is what to use over SSH or anywhere a window cannot open.
• raw-api — Raw (unstructured JSON) API commands.
• api — Low-level API commands.
• api-helper — Higher-level helper commands, layered on top of the plain API wrappers (retries, polling, data normalization).
• play — Run the solution for whatever file you name against its working directory's test cases, whether that's a puzzle or a contribution. Entirely local--no network access at all. Exists so one editor task can serve every working directory in a workspace: cg play --file ${file} needs to know neither which kind of working directory it's in nor where that directory is. Exits non-zero if any test fails.
• vscode — Editor integration for VS Code. All-or-nothing opt-in: nothing here is written unless you ask for it, and what is written is confined to entries cg names as its own.
• debug — Debug-session commands that work in any working directory, puzzle or contribution. The kind-agnostic counterparts of cg puzzle debug / cg contribution debug, taking a file instead of a directory and a test selection instead of a test argument--which is what lets one static VS Code launch configuration per language serve a whole workspace.
• contributions — List server-side contributions, one line per contribution (handle, id, status, puzzle type, title). By default lists all pending (community-review-queue) contributions from every author (Contribution/getAllPendingContributions); --personal lists only the logged-in codingamer's own contributions, any status (Contribution/getPersonalContributions). With --json (top-level option), prints the raw list instead--shape depends on which endpoint was used (CgPendingContribution vs CgPersonalContribution--no unified schema between the two yet).
• contribution — Contribution working directory commands--manage a local, possibly-uncommitted working view of a single contribution, backed by a real git repo (see codingame_tools.contribution_manager.manager for the main/server/version-data branch design). See cg api contribution/cg api-helper contribution for the raw, stateless API this is built on.
• puzzle — Puzzle working directory commands--solve an existing CodinGame puzzle locally. Much simpler than cg contribution: exactly one file (data/solution.src) is ever editable, so there's no git repo involved--see codingame_tools.puzzle_manager.manager's module docstring. Currently only classic PUZZLE_INOUT puzzles are supported.
• docker — Manage the Docker containers and images cg builds for languages that run in a container. One image carries every language cg can containerize (see cg docker toolchain list); C++ is currently the one with a container-backed build, run and debug path. Nothing here holds anything you authored--see cg docker clean.
• config — Configuration commands.
• settings — Settings commands (app-managed persistent state in settings.json, as opposed to the user-edited config.yaml--see cg config).

cg content-hash

Compute a content hash from stdin content.

usage: cg content-hash [-h]

cg login

Log in and save the credentials. By default, opens a browser window for the user to log in interactively.

usage: cg login [-h] [--force] [--no-validate] [--manual] [--remember-me REMEMBER_ME]
                [--cg-session CG_SESSION] [--clean] [--timeout SECONDS]

Options

• -f, --force — Force a login even if persistent credentials already exist. By default, login is skipped if credentials already exist for the profile. Note that freshness of credentials is not checked in any case; if they are expired, the client will fail to use them.
• -q, --no-validate — Skip validation of the credentials after login.
• -m, --manual — Perform manual login instead of browser login. Implied by presence of --remember-me or --cg-session.
• -r, --remember-me REMEMBER_ME — Remember me cookie value, for manual (non-browser) login.
• -s, --cg-session CG_SESSION — cgSession cookie value, for manual (non-browser) login.
• -c, --clean — If a browser is created, force a clean browser profile and a fresh login flow. By default, the existing browser session state is used if it exists, so that repeated logins for the same profile are generally automatic.
• -t, --timeout SECONDS (default: 300.0) — Maximum seconds to wait for browser login completion (default: 300).

cg logout

Log out of a given profile's session.

usage: cg logout [-h] [--keep-browser-session]

Options

• -k, --keep-browser-session — Keep the existing browser session even when logging out of the profile. If the browser session is logged in, it will remain logged in and will auto-login without user authentication at the next profile login. By default, the browser session is deleted on logout, which will require a full login flow in the browser.

cg whoami

Show the current logged-in user and other session info for the given profile.

usage: cg whoami [-h]

cg status

Summarize the current session: login status, profile details, and points/rank stats for the logged-in codingamer. Always hits the network--there's no cached/local mode, unlike cg contribution status/cg puzzle status (that's the whole point of this command). "Gamer stats" are informational, not a breakdown of one another--see CgCodingamePointsRankingDto's docstring for why. With --json (top-level option), renders as JSON instead of text.

usage: cg status [-h]

cg doc

Open the documentation for this version of cg in a dedicated browser window. The published site keeps every release side by side, so this opens the directory matching the cg you are actually running rather than whatever is newest. Inside a source checkout it serves that tree's own docs instead--including uncommitted edits--and stops the server when the window closes. With --url, prints the address and exits, which is what to use over SSH or anywhere a window cannot open.

usage: cg doc [-h] [--url] [--online] [--version VERSION] [--no-rebuild] [--windowed]

Options

• --url — Print the documentation URL and exit instead of opening a window. Use this over SSH, in a container, or anywhere a browser cannot open. In a source checkout this prints the published URL, since a local server would stop the moment this command returned.
• --online — Use the published site even inside a source checkout.
• --version VERSION — Show the documentation for a specific cg version (e.g. 2.0.1) instead of the installed one. Implies --online, since only the published site has other versions.
• --no-rebuild — In a source checkout, serve the existing site/ build instead of building first. Much faster to open, but shows the docs as of the last cg doc run. Both build into and read from a per-user cache directory, never the checkout, so this serves exactly what the previous run showed. Ignored when using the published site.
• --windowed — Open an ordinary browser window with an address bar, instead of a chrome-less app window. Use this if the app window misbehaves.

cg play

Run the solution for whatever file you name against its working directory's test cases, whether that's a puzzle or a contribution. Entirely local--no network access at all. Exists so one editor task can serve every working directory in a workspace: cg play --file ${file} needs to know neither which kind of working directory it's in nor where that directory is. Exits non-zero if any test fails.

usage: cg play [-h] [--file FILE] [--selected] [--timeout SECONDS] [--build-timeout SECONDS]
               [--workspace-root DIR]

Options

• -f, --file FILE — Any file inside the working directory to run--normally VS Code's ${file}. Its kind (puzzle or contribution) and root are both inferred from it. Defaults to discovering a working directory from the current directory.
• -s, --selected — Run only the test case selected for debugging (see cg puzzle select-test/cg contribution select-test) instead of all of them.
• --timeout SECONDS (default: 10.0) — Per-test-case run timeout in seconds.
• --build-timeout SECONDS (default: 120.0) — Build timeout in seconds, for compiled languages.
• --workspace-root DIR — The editor workspace root containing the working directory--normally VS Code's ${workspaceFolder}. Only matters for containerized languages, which bind-mount it so in-container paths match host paths; passing it explicitly beats cg's own guess. Defaults to searching upward for a .vscode/ or VCS directory.

cg vscode

Editor integration for VS Code. All-or-nothing opt-in: nothing here is written unless you ask for it, and what is written is confined to entries cg names as its own.

usage: cg vscode [-h] COMMAND ...

Subcommands

• install — Install cg's VS Code run/debug configuration. What it writes is the same for every working directory of a given language, so this is run once per language rather than once per working directory--and never again after an import, repair, or language change. With --file, sets up just that file's working directory; with no arguments, every working directory cg can find (the one you are standing in, plus the active puzzle and contribution). Writes into the workspace root's .vscode/ (VS Code only reads launch.json from the workspace root, never from a subdirectory), merging with what is already there: it replaces only the entries it generated, leaves yours alone, and does not touch a file whose content would not change.

cg vscode install

Install cg's VS Code run/debug configuration. What it writes is the same for every working directory of a given language, so this is run once per language rather than once per working directory--and never again after an import, repair, or language change. With --file, sets up just that file's working directory; with no arguments, every working directory cg can find (the one you are standing in, plus the active puzzle and contribution). Writes into the workspace root's .vscode/ (VS Code only reads launch.json from the workspace root, never from a subdirectory), merging with what is already there: it replaces only the entries it generated, leaves yours alone, and does not touch a file whose content would not change.

usage: cg vscode install [-h] [--file FILE] [--workspace-dir DIR] [--force] [--check]
                         [--debug-adapter-logging]

Options

• -f, --file FILE — Set up only the working directory this file belongs to. Defaults to every working directory cg can find.
• --workspace-dir DIR — Workspace root to write .vscode/ into. Defaults to the nearest enclosing directory that already has a .vscode/, then the nearest one under version control, then the working directory itself.
• --force — Overwrite an existing .vscode/ config file that isn't strict JSON (VS Code allows comments there, which can't be merged into safely). Without this, such a file is left untouched and an error is reported.
• --check — Report what would change and exit non-zero if anything would, without writing. Use it to find out whether a cg upgrade changed the generated configuration--there is no version stamp to compare, because the generated content is the version.
• --debug-adapter-logging — Generate a configuration that logs the debug adapter's own conversation with the debugger to the Debug Console. For diagnosing a session that misbehaves when everything underneath it works: the adapter is the one part of the stack that can't be exercised from a terminal. Loud and slow--re-run without it to turn it back off.

cg debug

Debug-session commands that work in any working directory, puzzle or contribution. The kind-agnostic counterparts of cg puzzle debug / cg contribution debug, taking a file instead of a directory and a test selection instead of a test argument--which is what lets one static VS Code launch configuration per language serve a whole workspace.

usage: cg debug [-h] COMMAND ...

Subcommands

• start — Build the debug profile and start a stopped debug target fed by the working directory's selected test case, ready for a debugger to attach. Prints the connection details. Which test is selected comes from .meta/ (see cg puzzle select-test / cg contribution select-test), defaulting to the first test case--so this command needs no test argument, and a launch configuration wiring it to a preLaunchTask never has to be regenerated.
• stop — Stop a debug target started by cg debug start. Always succeeds, including when nothing is running--it's wired to a postDebugTask, which fires even for a session that never really began.

cg debug start

Build the debug profile and start a stopped debug target fed by the working directory's selected test case, ready for a debugger to attach. Prints the connection details. Which test is selected comes from .meta/ (see cg puzzle select-test / cg contribution select-test), defaulting to the first test case--so this command needs no test argument, and a launch configuration wiring it to a preLaunchTask never has to be regenerated.

usage: cg debug start [-h] [--file FILE] [--build-timeout SECONDS] [--workspace-root DIR]

Options

• -f, --file FILE — Any file inside the working directory to debug--normally VS Code's ${file}. Its kind (puzzle or contribution) and root are both inferred from it. Defaults to discovering a working directory from the current directory.
• --build-timeout SECONDS (default: 120.0) — Wall-clock timeout for the debug build.
• --workspace-root DIR — The editor workspace root containing the working directory--normally VS Code's ${workspaceFolder}. Only matters for containerized languages, which bind-mount it so in-container paths match host paths; passing it explicitly beats cg's own guess. Defaults to searching upward for a .vscode/ or VCS directory.

cg debug stop

Stop a debug target started by cg debug start. Always succeeds, including when nothing is running--it's wired to a postDebugTask, which fires even for a session that never really began.

usage: cg debug stop [-h] [--file FILE] [--workspace-root DIR]

Options

• -f, --file FILE — Any file inside the working directory whose debug session to stop--normally VS Code's ${file}. Defaults to discovering a working directory from the current directory.
• --workspace-root DIR — The editor workspace root containing the working directory--normally VS Code's ${workspaceFolder}. Only matters for containerized languages, which bind-mount it so in-container paths match host paths; passing it explicitly beats cg's own guess. Defaults to searching upward for a .vscode/ or VCS directory.

cg contributions

List server-side contributions, one line per contribution (handle, id, status, puzzle type, title). By default lists all pending (community-review-queue) contributions from every author (Contribution/getAllPendingContributions); --personal lists only the logged-in codingamer's own contributions, any status (Contribution/getPersonalContributions). With --json (top-level option), prints the raw list instead--shape depends on which endpoint was used (CgPendingContribution vs CgPersonalContribution--no unified schema between the two yet).

usage: cg contributions [-h] [--personal]

Options

• --personal — List only the logged-in codingamer's own contributions (any status), instead of all pending contributions from every author.

---

Generated from the parser itself. For when to use these, see the CLI guides.